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: Billy_Biggs@3com
http://www.div8.net/billy/      Phone: Billy_Biggs@sip.3com.com