[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Megaco] Sending tones via the other subscriber's ephemeral
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
>
>
>
>
> -----Original Message-----
> *From: Al Varney [SMTP:varney@ieee.org]*
> *Sent: * Monday, 06 May, 2002 5:47 PM
> *To: * 'megaco@ietf.org'
> *Subject: * Re: [Megaco] Sending tones via the other
> subscriber's ephemeral
>
> At 01:04 PM 5/6/02 +0530, vibansal@hss.hns.com 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 <raphael@tdsoft.com> 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
> "megaco@fore.com" mailing list. Two years ago (6/27/00) it was
> discussed
> on the "MEGACO@standards.nortelnetworks.com" 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
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
--
-------------------------------------------------------
Terry L Anderson, DMTS tla@lucent.com
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
-------------------------------------------------------
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco