Subject: [SIP] Deprecate Early Media

From: Billy Biggs <[email-masked]>
Date: Tue, 21 Nov 2000 15:15:18 -0600

1 Deprecate Early Media

  Listed below are some severe problems with early media.  These
  problems can be solved by connecting (200 OK) before sending media.
  This creates a billing problem for PSTN gateways which can be solved
  by either:

  1. Separating the billing system from the SIP signalling.  Everyone
     sends detailed CDRs via non-SIP means.

  2. Changing the billing contract to charge for ringback and error
     sessions, just like AT&T cell phones do today.

  The issues listed below are causing us immediate problems.  I focus on
  PSTN gateways, but the arguments apply to other uses of early media.

  While this has come up before on the list and been ignored, I feel
  that early media should be deprecated quickly to avoid a larger mess.

  Comments appreciated.

2 History of Early Media

  The early media concept originated with the need for PSTN-style inband
  altering.  The primary reason for not initiating a full SIP session was
  for billing reasons.  As Steve Donovan wrote, "[we] Need [the] ability
  to have media session setup prior to network-to-network charging." [1]

  See [2] for more historical context.

  Apart from that, early media is convenient for gateways as it makes
  the mapping from Q.931 to SIP more direct.

3 Current Major Problems

  3.1 Services Which Use Early Two-Way Audio/Signalling
  3.2 Gateways Which Can't Determine Call Failure
  3.3 Handling by Forking Proxies which Fork the Call in Parallel
  3.4 Handling by Forking Proxies who Sequentially Fork the Call
  3.5 Inability to Provide User Recourse
  3.6 Difficult Negotiation of Media

3.1 Services Which Use Early Two-Way Audio/Signalling

  Some PSTN services, usually 800-number services, try and avoid being
  charged extra by deferring acceptance of a call as long as they can,
  relying on still receiving DTMF digits over the half-connected call.

  This was explained by Cliff Harris [3] as follows:

  "I believe that Q.931 does allow cut-through audio to be set up during
   the "overlapped dialing" phase of the call. In this scenario, while
   the caller is still issuing INFO messages containing the dialed
   digits, the callee sends a PROGRESS message indicating the presence
   of cut-through audio. The caller sets up an audio path in the
   backwards direction only.  Note that in this situation, the DTMF
   digits are being sent in the signalling path, not in the media path."

  Examples: 1-800-CALL-ATT, Verizon Wireless, American Airlines/United
            Reservations, and many other 1-800 IVR systems.

  As far as we can tell, there is no way for the gateway to identify
  this problem.

3.2 Gateways Which Can't Determine Call Failure

  Based on my experience, some PSTN gateways seem to have problems
  determining when the call has failed.  Henning mentioned this on the
  list [4]:

  "This goes back to an earlier, long-ago discussion whether it's better
   to use 4xx/5xx for announcements, but if I remember right, the
   conclusion was that this wasn't always feasible since gateways
   wouldn't be able to distinguish failure announcements from ring tone.
   (I thought the announcement tri-tone was for stuff like that...)"

  In this sort of case, UAs which delay sending SDP until the ACK will
  think the call is still ringing when really a busy signal is being
  played.

3.3 Handling by Forking Proxies which Fork the Call in Parallel

  The most obvious problem is when a call forks in parallel to two user
  agents, each which send early media.  As Henning mentioned [4]:

  "If "early media" is an announcement like "the number you have dialed
   has been changed. The new number is ...", mixing with ring tone from
   another destination would be very confusing."

  The UA can't cancel the branches, and the proxy can't be expected to
  cancel branches which return SDP.

3.4 Handling by Forking Proxies which Sequentially Fork the Call

  The problem here is when gateways can't tell that they're sending an
  early busy signal.  The user dials a number, hears a busy signal, and
  hangs up before the proxy has a chance to time out and switch to the
  next contact.

  Even worse, you call through a proxy which first forks to one of these
  interactive IVRs, asking you for your PIN number.  As you're typing it
  in, the proxy cancels the branch and moves on to the next contact.

3.5 Inability to Provide User Recourse

  Without using reliable provisional responses, there is no method to
  allow a user agent to place early media on hold, redirect multiple
  incoming sessions, or otherwise change its session description short
  of shutting down the call request.

3.6 Difficult Negotiation of Media

  A complete system which relies on early media must support reliable
  provisional responses in order for RTCP to work properly.  Other
  description protocols may have more difficult problems.

4 References

  [1] http://www.ietf.org/proceedings/99jul/slides/mmusic-sip183-99jul/

  [2] http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-183-00.txt

  [3] http://lists.bell-labs.com/pipermail/sip/2000q3/002352.html

  [4] http://lists.bell-labs.com/pipermail/sip/2000q3/002297.html

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 21 Nov 2000 16:45:11 -0500

>   PSTN gateways, but the arguments apply to other uses of early media.

The sooner, the better... However, it should be noted that "early media"
has an additional advantage in that it does allow the caller to figure
out automatically when to start sending audio. If you had an automatic
caller (as is common for various telemarketers or when Al Gore calls you
at home before elections), it would not work. Not that I would consider
this a major problem, as this appears only when calling IVR systems
which presumably don't buy aluminum siding and are too dumb to even
create a pregnant chad.

For those cases, where the gateway can determine when the call has been
connected, sending a re-INVITE to update the sendonly/recvonly
designation would seem to be preferable.

For billing, I'm not sure that early media is particularly useful except
possibly in the case of bridging ISUP islands. The direction indication
in SDP would help here, too. For gateways, the gateway presumably knows
how long the call into the PSTN was and can thus bill accordingly. I
assume gateways are smart enough to recognize the three-tone sequence
even if they are not ISUP connected. For IP billing, billing based on
resource reservation is the only long-term feasible approach in any
event.

A related question is whether any SIP implementations actually handle
early media. It seems harmless to have in pure IP systems, if it gets
never exercised by gateways.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Billy Biggs <[email-masked]>
Date: Tue, 21 Nov 2000 16:36:21 -0600

Henning,

  Thanks for your support. :)

> early media.

  You missed my urgency.  For the past 11 months I have been unable to
use 1-800 IVRs from the only phone on my desk, and get to see my phone
say 'Ringing' when I'm clearly hearing a busy signal.

  Quite frankly, I'm fed up.

  Yes, phones already receive it, and gateways already send it.

> [...] It seems harmless to have in pure IP systems, if it gets never
> exercised by gateways.

  I'm not sure what you mean.  Without any gateways, you still have all
the forking problems, the need for reliable provisional responses, ...
It's still a big mess.