Subject: RE: [Megaco] Sending tones via the other subscriber's ephemeral

From: Raphael Tryster <[email-masked]>
Date: Tue, 7 May 2002 10:36:10 +0200

Thanks Al and Vivek.

Your answers make sense to me, which leads me to ask if the examples in RFC
3015 and other places like draft-ietf-megaco-callflows-00.txt are wrong.
All the examples I have seen show ringback being provided by MGA.
Furthermore, some of the examples show the termination modes being recvonly
until the called party goes off-hook.  If this is the case, then the
half-duplex connection to which Vivek refers is in the wrong direction.  If
EphB in my example is recvonly, then it cannot send the tone to EphA.  Have
all the example writers been oversimplifying to the point of misleading?

Raphael Tryster

	-----Original Message-----
	From:	Al Varney [SMTP:[email-masked]]
	Sent:	Monday, 06 May, 2002 5:47 PM
	To:	[email-masked]'
	Subject:	Re: [Megaco] Sending tones via the other
subscriber's ephemeral

	At 01:04 PM 5/6/02 +0530, [email-masked] wrote:
	>It is recomanded that  ringback tone id be played by the
terminating media
	>gateway. So in  this case, MGC controlling MGB tells MGB to send
ringback 
	>signal
	>on EphB,  MGB at australia would play the ringback tone on the
ephemeral
	>termination EphB,  and subscriber A would hear Australian ringback
tone 
	>,as half
	>duplex connection is already open.

	    I'm not sure where this is "recommended" rather than "required",
except 
	in cases where MGA and MGB operate together as a single logical
switching 
	entity (a distributed PBX, perhaps).

	>>Raphael Tryster <[email-masked]> wrote on 05/05/2002 10:02:45
PM
	>>
	>>Is the following a realistic scenario?
	>>
	>>Subscriber A in U.S.A. wishes to speak with subscriber B in
Australia.  When
	>>the connection is established (MGA creates EphA in the same
context as PhyA,
	>>and MGB creates EphB in the same context as PhyB) and B's phone is
ringing,
	>>the MGC controlling MGA sends a ringback signal to PhyA.  But this
would be
	>>an American ringback signal, and A wants to know he is calling
Australia.
	>>So instead, the MGC controlling MGB tells MGB to send ringback
signal on
	>>EphB.
	>>
	>>Will this work, i.e. will subscriber A hear Australian ringback
tone?  And
	>>is it done in practice?

	    If by "in practice" you mean "in the existing telephone
network", you 
	will find ringback tone ALWAYS comes from the terminating switch 
	(pre-MGC/MG).  There are several reasons for this:

	  - MGA would never know when to apply ringback, since it has no
knowledge 
	of the status of the terminating line.  In fact, it doesn't know if
MGB is 
	a terminating point or just an interworking point using traditional 
	trunking to reach a third switching point (perhaps located in a
third country).

	  - MGA would not be aware (at ringback time) of cases where MGB is 
	forwarding the call to another line somewhere in the world, or is 
	interacting with an Intelligent Network service or is offering a
voice 
	announcement regarding the status of the called number.  (E.g.,
"this 
	number is disconnected, calls are being taken on XXX-XXXX-XXX".)

	  - MGA (and any other MGs on the way to the final terminating MG)
would 
	have to be very quick in order for MGA to be able to remove ringback
and 
	cut through the connection before the called party's "Hello?" is
transmitted.

	    About a year ago (5/1/01), I discussed this same issue on the 
	"[email-masked]" mailing list.  Two years ago (6/27/00) it was
discussed 
	on the "[email-masked]" mailing list.  And I've

	discussed it ad nauseam on several other standards lists (H.248,
SIP, 
	H.323, ISUP/BICC) over the past few years.  Here's the rationale in
a 
	single sentence:

	        "The PSTN does not, in general, provide a reliable
	         out-of-band indication of when Alerting of the
	         called party is occurring."
	            -  (quoting an ITU-T contribution)

	    I assume this will continue to come up until the H.323, H.248
and SIP 
	folks finally get something published that shows real-world examples
of the 
	need to provide ringback from the terminating end of a connection.
(See 
	the SIP "183 Session Progress" message for some examples.)

	    Thanks, Raphael, for providing this year's version of the
perennial 
	question.  Should you wish to examine other standards/requirements
on this 
	issue, note the ITU-T uses the term "Ring Tone" and Telcordia the
term 
	"audible ring tone" in many telephony documents.  "Ringback" seems
to have 
	originated in PBX/ISDN documents in North America in the 1980s.

	Al Varney

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

---

From: Al Varney <[email-masked]>
Date: Tue, 07 May 2002 05:51:23 -0500

At 10:36 AM 5/7/02 +0200, Raphael Tryster wrote:
>Thanks Al and Vivek.
>
>Your answers make sense to me, which leads me to ask if the examples in 
>RFC 3015 and other places like draft-ietf-megaco-callflows-00.txt are 
>wrong.  All the examples I have seen show ringback being provided by MGA.

    All of the examples of RFC 3015 show the MGs controlled by a single 
MGC, since the authors (and A-D) wished to avoid any implications regarding 
the MGC-to-MGC signaling issues.  For example, the issue of when ephemeral 
SDP information is known between MGCs can be ignored, as can the issue of 
what/where call progress information is available and the issue of when 
cut-through of media flow should occur during call establishment.

    The "megaco-callflows" draft has lots of examples, and I'd certainly 
hesitate to use the word "wrong" for all of them.  However, the 2.5 and 2.6 
sections (RGW to SS7 TGW and reverse) don't match the expectations of ISUP 
switches, so they are certainly "wrong" in that sense.  (That is, they 
won't interwork with the existing ISUP network, so the draft at least 
contains "errors".)  I don't think the authors understood Q.764 (ITU-T 
ISUP) and variants like ANSI T1.113 (North American ISUP).

    These particular examples don't seem to follow the call establishment 
scenarios used (finally) in similar SIP-to-ISUP call examples.  See: 
<draft-ietf-sipping-isup-01.txt> for details.

>  Furthermore, some of the examples show the termination modes being 
> recvonly until the called party goes off-hook.  If this is the case, then 
> the half-duplex connection to which Vivek refers is in the wrong 
> direction.  If EphB in my example is recvonly, then it cannot send the 
> tone to EphA.  Have all the example writers been oversimplifying to the 
> point of misleading?

    No.  Certainly the Megaco effort has focused on the MGC-MG 
interactions, and the examples are designed to demonstrate the 
protocol.  The examples (if any) in inter-MGC communication standards is 
largely correct (ISUP, for example, describes the appropriate generation of 
ringback for ISUP switches).  SIP has focused on the inter-MGC protocol (as 
a protocol document should), and largely ignored the details of what/when 
media manipulation occurs.

    (Regarding your specific recvonly statement, I believe EphB can send 
tones even in recvonly.  Signals are not affected by "mode", per the 
RFC.  But that's an aside.)

    It is my impression that IETF does not recognize standards-track 
documents specifying non-protocol or implementation issues (such as the 
provision of ringback and cut-through of media channels in a system using 
Megaco and SIP together), so we'll probably continue to see a series of 
"callflow" documents generated by SIP, Megaco, and other groups.  Since 
they are just examples (and short-lived drafts), it will be difficult (and 
frustrating) to try to keep up with all of them.

    Eventually, testing and the real world will resolve any "misleading" 
issues, but there won't be any long-lived IETF documents describing call 
flows for newer users.  They too will learn by doing/testing.  Or do I 
mis-understand the IETF process?

Al Varney

---

From: Al Varney <[email-masked]>
Date: Tue, 07 May 2002 05:51:23 -0500

Al Varney

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 07 May 2002 09:58:25 -0400

I don't believe that H.248 imposes a rule on which MG (if any) should 
generate a ringback tone.  That is up to the MGC.  It could choose to 
use a signal on the terminating MG's ephemeral termination or the 
originating MG's PSTN or physical termination, or even propogate a 
ringback tone received on the terminating MG's PSTN termination.  It is 
up to the MGC to manage call flow details and H.248 allows MGCs a lot of 
freedom to manage their MGs.  The circuit-switched network that we are 
imitating also uses both options on various switches.

Raphael Tryster wrote:

> Thanks Al and Vivek.
>
> Your answers make sense to me, which leads me to ask if the examples 
> in RFC 3015 and other places like draft-ietf-megaco-callflows-00.txt 
> are wrong.  All the examples I have seen show ringback being provided 
> by MGA.  Furthermore, some of the examples show the termination modes 
> being recvonly until the called party goes off-hook.  If this is the 
> case, then the half-duplex connection to which Vivek refers is in the 
> wrong direction.  If EphB in my example is recvonly, then it cannot 
> send the tone to EphA.  Have all the example writers been 
> oversimplifying to the point of misleading?
>
> Raphael Tryster
>
>
>
>
>       *From:   Al Varney [SMTP:[email-masked]]*
>       *Sent:  * Monday, 06 May, 2002 5:47 PM
>       *To:    * [email-masked]'
>       *Subject:       * Re: [Megaco] Sending tones via the other
>       subscriber's ephemeral
>
>       >gateway. So in  this case, MGC controlling MGB tells MGB to
>       send ringback
>       >signal
>       >termination EphB,  and subscriber A would hear Australian
>       ringback tone
>       >,as half
>           I'm not sure where this is "recommended" rather than
>       "required", except
>       >>Raphael Tryster <[email-masked]> wrote on 05/05/2002
>       10:02:45 PM
>       >>
>       >>and MGB creates EphB in the same context as PhyB) and B's
>       phone is ringing,
>       >>the MGC controlling MGA sends a ringback signal to PhyA.  But
>       this would be
>       >>Will this work, i.e. will subscriber A hear Australian
>       ringback tone?  And
>       >>is it done in practice?
>
>       of the status of the terminating line.  In fact, it doesn't know
>       if MGB is
>         - MGA (and any other MGs on the way to the final terminating
>       MG) would
>       have to be very quick in order for MGA to be able to remove
>       ringback and
>       H.323, ISUP/BICC) over the past few years.  Here's the rationale
>       in a
>       single sentence:
>
>           I assume this will continue to come up until the H.323,
>       H.248 and SIP
>       folks finally get something published that shows real-world
>       examples of the
>       need to provide ringback from the terminating end of a
>       connection.  (See
>       question.  Should you wish to examine other
>       standards/requirements on this
>       issue, note the ITU-T uses the term "Ring Tone" and Telcordia
>       the term
>       "audible ring tone" in many telephony documents.  "Ringback"
>       seems to have

-- 
-------------------------------------------------------
Terry L Anderson, DMTS                   [email-masked]
Lucent Technologies /INS/ Voice over IP Access Networks
Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
Voice:908 582-7013  FAX:908 582-6226   Org:18E75000000
http://its.lucent.com/~tla  (Lucent internal)
http://www.gti.net/tla
-------------------------------------------------------

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 07 May 2002 09:58:25 -0400

---

From: Christian Groves <[email-masked]>
Date: Wed, 08 May 2002 10:10:02 +1000

Please bear in mind that call flows both in the Appendix of H.248/Megaco and
draft-ietf-megaco-callflows-00.txt are INFORMATIVE. Its not a particularly good
idea to base a commerical product around them as they are rather limited. For
good interoperability normative specifications are needed profiling how
SIP/ISUP/BICC/Megaco etc are used in a system. ITU Q.1950 and 3GPP 29.232 go
part of the way to acheive this for Megaco in BICC in ITU and 3G networks.
However even in the referenced BICC call flows in ITU are informative.

Regards, Christian

Raphael Tryster wrote:
> 3015 and other places like draft-ietf-megaco-callflows-00.txt are wrong.  All
> the examples I have seen show ringback being provided by MGA.  Furthermore,
> some of the examples show the termination modes being recvonly until the
> called party goes off-hook.  If this is the case, then the half-duplex
> connection to which Vivek refers is in the wrong direction.  If EphB in my
> example is recvonly, then it cannot send the tone to EphA.  Have all the
> example writers been oversimplifying to the point of misleading?
> 
> Raphael Tryster
> 
>      Subject:        Re: [Megaco] Sending tones via the other subscriber's
>      ephemeral
> 
>      >It is recomanded that  ringback tone id be played by the terminating
>      media
>      >on EphB,  MGB at australia would play the ringback tone on the ephemeral
> 
>      >termination EphB,  and subscriber A would hear Australian ringback tone
>      >,as half
>      in cases where MGA and MGB operate together as a single logical switching
> 
>      >>Raphael Tryster <[email-masked]> wrote on 05/05/2002 10:02:45 PM
>      >>
>      >>Subscriber A in U.S.A. wishes to speak with subscriber B in Australia.
>      When
>      >>the connection is established (MGA creates EphA in the same context as
>      PhyA,
>      >>So instead, the MGC controlling MGB tells MGB to send ringback signal
>      on
>      >>EphB.
>      >>
>      >>Will this work, i.e. will subscriber A hear Australian ringback tone?
>      And
>      >>is it done in practice?
> 
>          If by "in practice" you mean "in the existing telephone network", you
> 
>      of the status of the terminating line.  In fact, it doesn't know if MGB
>      is
>      trunking to reach a third switching point (perhaps located in a third
>      country).
> 
>      interacting with an Intelligent Network service or is offering a voice
>      announcement regarding the status of the called number.  (E.g., "this
>        - MGA (and any other MGs on the way to the final terminating MG) would
>      have to be very quick in order for MGA to be able to remove ringback and
>      "[email-masked]" mailing list.  Two years ago (6/27/00) it was discussed
> 
>      discussed it ad nauseam on several other standards lists (H.248, SIP,
>      H.323, ISUP/BICC) over the past few years.  Here's the rationale in a
>      single sentence:
> 
>          I assume this will continue to come up until the H.323, H.248 and SIP
> 
>      folks finally get something published that shows real-world examples of
>      the
>      need to provide ringback from the terminating end of a connection.  (See
>          Thanks, Raphael, for providing this year's version of the perennial
>      question.  Should you wish to examine other standards/requirements on
>      this
>      issue, note the ITU-T uses the term "Ring Tone" and Telcordia the term
>      "audible ring tone" in many telephony documents.  "Ringback" seems to
>      have

---

From: Christian Groves <[email-masked]>
Date: Wed, 08 May 2002 10:10:02 +1000

Regards, Christian