[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] Early media as an endpoint application

Dan,

I support a draft that relays a CN, but would have issues with the IETF
addressing issues WRT when billing/charging should begin and end.

Martin 

-----Original Message-----
From: Dan York [mailto:dyork at voxeo.com] 
Sent: Thursday, August 21, 2008 7:37 PM
To: DOLLY, MARTIN C, ATTLABS; sip-bounces at ietf.org; Henry Sinnreich;
Dean Willis; Dwight, Timothy M (Tim)
Cc: sip at ietf.org; ekr at rtfm.comFrom sip-bounces at ietf.org  Thu Aug 21 16:47:17 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-web-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 44A513A6BD1;
	Thu, 21 Aug 2008 16:47:17 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 450B33A6809;
	Thu, 21 Aug 2008 16:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.372
X-Spam-Level: 
X-Spam-Status: No, score=-105.372 tagged_above=-999 required=5
	tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455,
	RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id oD09lLL4iWbD; Thu, 21 Aug 2008 16:45:28 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com
	[216.82.250.83])
	by core3.amsl.com (Postfix) with ESMTP id 4D66828C119;
	Thu, 21 Aug 2008 16:45:24 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: mdolly at att.com
X-Msg-Ref: server-3.tower-120.messagelabs.com!1219362276!34432035!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 21837 invoked from network); 21 Aug 2008 23:44:37 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com)
	(144.160.20.54)
	by server-3.tower-120.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Aug 2008 23:44:37 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	m7LNiahQ028439; Thu, 21 Aug 2008 19:44:36 -0400
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com
	[135.53.26.19])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	m7LNiWBt028422; Thu, 21 Aug 2008 19:44:33 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 21 Aug 2008 19:44:32 -0400
Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA56E374 at gaalpa1msgusr7e.ugd.att.com>
In-Reply-To: <2111245615-1219361799-cardhu_decombobulator_blackberry.rim.net-2145149396- at bxe025.bisx.prod.on.blackberry>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Early media as an endpoint application
Thread-Index: AckD5saC4jpJeeQAQrqmTOyOFEz5MQAAOq6w
References: <B328D2F6-AE16-40CB-B4AE-5BD59CFA5F7D at softarmor.com><C4D3467D.7CF3%hsinnrei at adobe.com><14C85D6CCBE92743AF33663BF5D24EBA56E371 at gaalpa1msgusr7e.ugd.att.com>
	<2111245615-1219361799-cardhu_decombobulator_blackberry.rim.net-2145149396- at bxe025.bisx.prod.on.blackberry>
From: "DOLLY, MARTIN C, ATTLABS" <mdolly at att.com>
To: <dyork at voxeo.com>, <sip-bounces at ietf.org>,
	"Henry Sinnreich" <hsinnrei at adobe.com>,
	"Dean Willis" <dean.willis at softarmor.com>,
	"Dwight, Timothy M (Tim)" <timothy.dwight at verizonbusiness.com>
Cc: sip at ietf.org, ekr at rtfm.com, Dan Wing <dwing at Cisco.COM>
Subject: Re: [Sip] Early media as an endpoint application
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org

Dan,

I support a draft that relays a CN, but would have issues with the IETF
addressing issues WRT when billing/charging should begin and end.

Martin 

-----Original Message-----
From: Dan York [mailto:dyork at voxeo.com] 
Sent: Thursday, August 21, 2008 7:37 PM
To: DOLLY, MARTIN C, ATTLABS; sip-bounces at ietf.org; Henry Sinnreich;
Dean Willis; Dwight, Timothy M (Tim)
Cc: sip at ietf.org; ekr@; Dan Wing
Subject: Re: [Sip] Early media as an endpoint application

Martin,

To a certain degree, some of us have already been taking on the
billing/charging question. See my P-Charge-Info draft (which I have been
told in comments today is doing something similar to the ISUP Charge
Number parameter).

Dan
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     dyork at voxeo.com
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com



-----Original Message-----
From: "DOLLY, MARTIN C, ATTLABS" <mdolly at att.com>

Date: Thu, 21 Aug 2008 19:04:34 
To: Henry Sinnreich<hsinnrei at adobe.com>; Dean
Willis<dean.willis at softarmor.com>; Dwight, Timothy M
(Tim)<timothy.dwight at verizonbusiness.com>
Cc: <sip at ietf.org>; <ekr at rtfm.com>; Dan Wing<dwing at Cisco.COM>
Subject: Re: [Sip] Early media as an endpoint application


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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Henry Sinnreich
Sent: Thursday, August 21, 2008 5:21 PM
To: Dean Willis; Dwight, Timothy M (Tim)
Cc: sip at ietf.org; ekr at rtfm.com; 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" <dean.willis at softarmor.com> 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, thatrtfm.com; Dan Wing
Subject: Re: [Sip] Early media as an endpoint application

Martin,

To a certain degree, some of us have already been taking on the
billing/charging question. See my P-Charge-Info draft (which I have been
told in comments today is doing something similar to the ISUP Charge
Number parameter).

Dan
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     dyork at voxeo.com
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com



-----Original Message-----
From: "DOLLY, MARTIN C, ATTLABS" <mdolly at att.com>

Date: Thu, 21 Aug 2008 19:04:34 
To: Henry Sinnreich<hsinnrei at adobe.com>; Dean
Willis<dean.willis at softarmor.com>; Dwight, Timothy M
(Tim)<timothy.dwight at verizonbusiness.com>
Cc: <sip at ietf.org>; <ekr at rtfm.com>; Dan Wing<dwing at Cisco.COM>
Subject: Re: [Sip] Early media as an endpoint application


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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Henry Sinnreich
Sent: Thursday, August 21, 2008 5:21 PM
To: Dean Willis; Dwight, Timothy M (Tim)
Cc: sip at ietf.org; ekr at rtfm.com; 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" <dean.willis at softarmor.com> 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 gatew'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
_______________________________________________
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
_______________________________________________
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


ay, 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
_______________________________________________
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
_______________________________________________
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