Perhaps I am missing some basic concepts
Raphael Tryster
-----Original Message-----
From: Al Varney [SMTP:varney@ieee.org]
Sent: Tuesday, 07 May, 2002 12:51 PM
To: megaco@ietf.org
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 "Courier New"> 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
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco