[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Early media as an endpoint application
I'm sorry but it seems pretty far-fetched to try and blame SIP
shortcomings on "Bell-heads". Since when have they (we) been that
influential?
My point to Henry was just that this "problem" is not specific to PSTN
gateways; so it wouldn't be appropriate to confine its solution to such
a device. The need for media interaction prior to call completion
(which as Martin notes can be 2-way) arises from the intermediated
service model; which is as applicable to VoIP as to circuit switched
networks.
Tim
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com]
> Sent: Thursday, August 21, 2008 2:54 PM
> To: Dwight, Timothy M (Tim)
> Cc: Henry Sinnreich; Dan Wing; sip at ietf.org; ekr at rtfm.com
> Subject: Re: [Sip] Early media as an endpoint application
>
>
> On Aug 21, 2008, at 10:37 AM, Dwight, Timothy M (Tim) wrote:
>
> > What if you want to implement those or similar services
> between VoIP
> > end
> > systems? For example what if you want to provide "color ringback
> > tones"
> > between VoIP end systems? There is no PSTN gateway involvement in
> > such
> > services.
>
> The problem with early media is that it assumes that there is a need
> to transfer media BEFORE a session is "established". We inherit this
> assumption from the PSTN, because the PSTN billing model allows one-
> way media to flow from destination to origin before the call is
> "established". It works only because the stateful-everything
> prevents
> multiple early media sessions. With SIP, and forking, we get chaos.
>
> So the "right answer" is to have two separate but fully
> negotiated SIP
> sessions -- one for the early media, one for the regular media. The
> second session, should it occur, replaces the first (and we have a
> signaling mechanism to do just that). This eliminates the
> whole (or at
> least most of) "early media" problem. But it confuses the
> heck out of
> bellheads who have decided to start billing based on the 200 OK, but
> also want to slavishly imitate the billing sequence of PSTN. It's
> stupid, broken, and can be manipulated to get vast amounts of "free
> long distance" out of the system, but it is deeply entrenched.
>
> More on this: In the model I'm describing, a PSTN gateway handling a
> call from SIP to PSTN would send an initial 200/sendonly on
> receipt of
> the ACM (or equivalent). This would give us a SIP session for the
> "early media" phase. Then the gateway could either reinvite or refer/
> replaces on the ANS.
>
> The problem with this is that, if you're billing on the INVITE/200
> transaction, a naive system starts billing on the first INVITE/200
> (the early media). So one needs a smarter billing system that 1)
> knows that the call is to a gateway, so it should start billing when
> the gateway initiates the bidirectional session, and 2) knows
> to bill
> the user, rather than the gateway. This could be helped by a SIP
> exetension of some sort that identifies the early 200 OK as "early"
>
> Now this isn't perfect, as if one forks a call, and one fork
> goes to a
> PSTN gateway, that's the fork you're going to get connected to every
> time, as it sends back the quickest 200 OK. But hey, if that's where
> you're getting media from, that's where you should be listening,
> right? Forking is broken. If it hurts, don't do it. Forking
> to a PSTN
> gateway really requires a B2BUA that understands the "early media
> session" model proposed above, and is smart enough to drop the early-
> media session if it gets a non-early 200 OK from another leg.
>
> On a pure VoIP system, localized ringback is probably better handled
> with extensions to "alert-info".
>
> --
> Dean
>
>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip