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

From: Raphael Tryster <[email-masked]>
Date: Sun, 5 May 2002 18:32:45 +0200

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?

Raphael Tryster

---

From: [email-masked]
Date: Mon, 6 May 2002 13:04:56 +0530

Hi

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

Regards
Vivek

www.hssworld.com

Raphael Tryster <[email-masked]> on 05/05/2002 10:02:45 PM

To:   "[email-masked]'" <[email-masked]>
cc:    (bcc: Vivek Bansal/HSS)

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

Raphael Tryster

---

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:
	>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
	>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
	>>Will this work, i.e. will subscriber A hear Australian ringback
tone?  And

	    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: Raphael Tryster <[email-masked]>
Date: Tue, 7 May 2002 15:36:41 +0200

Perhaps I am missing some basic concepts.  Questions inside, marked by
[FSRT].

Raphael Tryster

	-----Original Message-----
	From:	Al Varney [SMTP:[email-masked]]
	Sent:	Tuesday, 07 May, 2002 12:51 PM
	To:	[email-masked]
	Subject:	RE: [Megaco] Sending tones via the other
subscriber's ephemeral

	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.

	[FSRT]  Are you saying that because, in the simplified examples,
both MGs would give the same ringback tone, the local MG is given the job?
In other words, if both MGs are controlled by the same MGC, either MGA or
MGB can be asked to supply ringback.  However, for the reasons you have
given, in the general case MGB must supply the ringback.  So why treat a
special case differently when it is covered by the general case?

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

	[FSRT] A very interesting aside.  I can understand this statement in
the simple case where only one MG and MGC are involved.  For example, if a
termination is in sendonly mode and an MGC directs the MG to send it
dialtone, this can be done because we are not asking the termination to
receive anything from the interior of the context.  But sending ringback
from EphB to EphA seems different.  The same RTP resources needed to send
voice from EphB to EphA would be needed to send ringback tone from EphB to
EphA.  The difference is more acute at EphA, where the ringback tone has
nothing identifying it as a signal and is indistinguishable from voice.  If
EphA is sendonly, I don't see how the ringback could get through.

	    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: Raphael Tryster <[email-masked]>
Date: Tue, 7 May 2002 15:36:41 +0200

Raphael Tryster

	-----Original Message-----
	From:	Al Varney [SMTP:[email-masked]]
	Sent:	Tuesday, 07 May, 2002 12:51 PM
	To:	[email-masked]
	Subject:	RE: [Megaco] Sending tones via the other
subscriber's ephemeral

examples in 
are 
by MGA.

being 
case, then 
the 
to the 

	Al Varney

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 7 May 2002 10:01:29 -0400

I'm probably making a mistake, answering your note as I come to it rather
than reading to the end of the thread, but I'll make the following general
points:

(1) At any point where the MG is at a trust boundary, the MGC will normally
set the termination representing the caller into receiveOnly mode to start
with to prevent fraud.  All other terminations along the call path can be
made sendReceive from the beginning.

(2) Al's general rule on which MG supplies ringback is right: it would be
one connected to the terminating line.  It gets a little more complicated if
the MG is connected to a SIP network through which the call is terminated.
In that case, I would differentiate between a 183 Session Progress
provisional response, which suggests that ringback will come from further
along the media path, and a 180 Ringing provisional response, which suggests
that no ringback is being provided.

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Tuesday, May 07, 2002 4:36 AM
To: Al Varney; [email-masked]'
Subject: RE: [Megaco] Sending tones via the other subscriber's ephemeral

Thanks Al and Vivek. 

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

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 7 May 2002 10:01:29 -0400

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Tuesday, May 07, 2002 4:36 AM
To: Al Varney; [email-masked]'
Subject: RE: [Megaco] Sending tones via the other subscriber's ephemeral

Thanks Al and Vivek. 

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

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 7 May 2002 10:11:23 -0400

I wanted to address one specific process issue, snipped out from the rest of
your note.  The SIPPING WG, with the support of the ADs, is defining
standards track documentation describing how to use SIP for various
services.  This was initiated partly in response to SG 11 needs for
standardized usages.  We might be able to persuade the IESG to let us do the
same if the need becomes evident.

As for "errors" in the call flow documentation, please call them out by all
means, and we'll get them fixes.

-----Original Message-----
From: Al Varney [mailto:[email-masked]]
Sent: Tuesday, May 07, 2002 6:51 AM
To: [email-masked]
Subject: RE: [Megaco] Sending tones via the other subscriber's ephemeral

[snip]

    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