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:[EMAIL PROTECTED] 
> Sent: Thursday, August 21, 2008 2:54 PM
> To: Dwight, Timothy M (Tim)
> Cc: Henry Sinnreich; Dan Wing; [email protected]; [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to