Dean, Wrong, ISUP allows for media in both directions before answer.
Also, is the IETF taking on the topic of "billing/charging" now? Martin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henry Sinnreich Sent: Thursday, August 21, 2008 5:21 PM To: Dean Willis; Dwight, Timothy M (Tim) Cc: [email protected]; [EMAIL PROTECTED]; Dan Wing Subject: Re: [Sip] Early media as an endpoint application Dean, How would the proposed "Media Before Answer" endpoint/gateway application affect the billing in your opinion? Would it change anything with the issues here below? (The SIP servers in the network do not need to understand "Media Before Answer", they just do the rendezvous job) Henry On 8/21/08 2:54 PM, "Dean Willis" <[EMAIL PROTECTED]> wrote: > > 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
