Subject: Re: [MEDIACTRL] Query

From: "Eric Burger" <[email-masked]>
Date: Thu, 28 Feb 2008 05:41:46 -0800

True in theory. And yes, protocol design should not constrain business practice. However, does or will any for-profit entity expect to bill for media services this way?

Of course, the good news is the protocol has nothing to do with it. In the unlikely event someone figures out a profitable way of generating CDRs at a media server, the commercial media server vendors will use P-Charging-Vector. The really good news is if the media server conforms to 3261 today, you can happily burn the signaling bandwidth and send the header to the media server today. It will happily ignore it.

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

----- Original Message -----
From: DRAGE, Keith (Keith) <[email-masked]>
To: [email-masked] <[email-masked]>; Even, Roni <[email-masked]>; Eric Burger
Cc: [email-masked] <[email-masked]>
Sent: Thu Feb 28 05:31:05 2008
Subject: RE: [MEDIACTRL] Query

The generation of CDRs is nothing to do with call generation or termination in IMS.

If an entity adds value to a session or transaction, then that entity has the ability to generate a CDR to reflect the value added. A unique identity (which it receives in the P-Charging-Vector header) enables this to be correlated with CDRs generated by other entities, and thus enable the operator to generate a complete accounting of the call.

Therefore the MRFC is able to generate CDRs, as some of the functions it performs may well add value.

The MRFP is a media plane function that needs to be accounted separately.

Regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rahul
> Sent: Monday, February 25, 2008 7:53 AM
> To: 'Even, Roni'; 'Eric Burger'
> Cc: [email-masked]
> Subject: Re: [MEDIACTRL] Query
> 
> Thanks for your inputs :)
> Eric,
>       I also don't expect the Media Server to generate calls. 
> (aka start sending INVITE on its own).
> As per my understanding of IMS the MS (MRFC + MRFP) is 
> capable of intelligence of generating CDR if required to do so.
> 
> One use-case comes to my mind is as follows:
> MS should track all calls users which are bandwidth heavy e.g 
> video calls.
> Since AS is generally transparent to SDP (apart from version 
> and sessionid) it can generate data only if it knows some 
> call identifier which is unique in the network for the call.
> 
> Though I am yet to see this sort of services being used but 
> still theoretically it is possible as per IMS.
> 
> Roni,
>     Are you suggesting the MRFC part should be implemented by AS?
> As per my understanding the MS needs to implement both MRFC 
> and MRFP (but I haven't seen any MS which does so). I also 
> don't expect MRFP to understand P-CHARGING-VECTOR but MRFC 
> must have capability to understand the P-CHARGING-VECTOR and 
> thereby generating CDRs (as per the IMS at least).
> 
> 
> Regards,
> Rahul
> 
> 
>  
> 
> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Sunday, February 24, 2008 12:24 PM
> To: Eric Burger; [email-masked]
> Cc: [email-masked]
> Subject: RE: [MEDIACTRL] Query
> 
> Hi,
> I am also curious what you are calling as the Media Server per IMS.
> Is that the MRFC or MRFP.
> BTW: I assume you are talking about conference MS and not an 
> announcement or IVR MS
> 
> I would not expect an MRFP to add the P-CHARGING-VECTOR.
> If it is the MRFC separated from the AS (I am not sure which 
> protocol is
> used) I would expect the Application Server to supply it like 
> Eric said.
> Roni Even
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] 
> > On Behalf Of Eric Burger
> > Sent: Friday, February 22, 2008 5:08 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [MEDIACTRL] Query
> > 
> > [as an individual]
> > 
> > My belief, and, for eight years my evangelization, is that media 
> > servers ONLY terminate "calls" (in the IMS sense).  Since the 
> > application server creates or directs the media server to act on a 
> > billable event, charging is the responsibility of the application 
> > server.
> > 
> > For example, a conference dial-out is accomplished with 
> 3PCC driven by 
> > the application server; the "outbound" leg is really 
> outbound from the 
> > application server towards the target and another leg towards the 
> > media server.  Likewise, the application server effects a 
> transfer by 
> > issuing an INVITE to the target and pulling back the leg from the 
> > media server.  The media server NEVER issues an INVITE.
> > 
> > Do you have counter examples we should be aware of?
> > 
> > 
> > On 1/29/08 3:59 AM, "Rahul" <[email-masked]> wrote:
> > 
> > > Hi All,
> > >       This might not be the correct question for this 
> group. But I 
> > > want
> > to
> > > know in any vendor is supporting P-CHARGING-VECTOR header for the 
> > > Media Server.
> > > I know some media servers and they don¹t support this and 
> as per IMS
> > document
> > > the media server might generated CDR for which it require to 
> > > understand
> > this
> > > header.
> > >
> > > Regards,
> > > Rahul
> > 
> > 
> > Notice:  This email message, together with any attachments, may 
> > contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  
> > affiliated entities,  that may be confidential,  proprietary,  
> > copyrighted  and/or legally privileged, and is intended 
> solely for the 
> > use of the individual or entity named in this message. If 
> you are not 
> > the intended recipient, and have received this message in error, 
> > please immediately return this by email and then delete it.
> > _______________________________________________
> > MEDIACTRL mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 28 Feb 2008 14:50:56 +0100

Its not necessarily about profit or charging the end subscriber:

"At the end of this process, CDR files are generated by the network, which are then transferred to the network operator's Billing Domain for the purpose of subscriber billing and/or inter-operator accounting (or additional functions, e.g. statistics, at the operator’s discretion)." 

If I am providing a call distribution service to a customer, I may well want to know the utilisation of any MRFC associated with delivering those calls to that particular subscriber.

Regards

Keith

> From: Eric Burger [mailto:[email-masked]] 
> Sent: Thursday, February 28, 2008 1:42 PM
> To: DRAGE, Keith (Keith); [email-masked]; [email-masked]
> Cc: [email-masked]
> True in theory. And yes, protocol design should not constrain 
> business practice. However, does or will any for-profit 
> entity expect to bill for media services this way?
> 
> Of course, the good news is the protocol has nothing to do 
> with it. In the unlikely event someone figures out a 
> profitable way of generating CDRs at a media server, the 
> commercial media server vendors will use P-Charging-Vector. 
> The really good news is if the media server conforms to 3261 
> today, you can happily burn the signaling bandwidth and send 
> the header to the media server today. It will happily ignore it.
> 
> --
> Sent from my wireless e-mail device. Sorry if terse.  We all 
> need lemonade: see 
> <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.
> 
> If an entity adds value to a session or transaction, then 
> that entity has the ability to generate a CDR to reflect the 
> value added. A unique identity (which it receives in the 
> P-Charging-Vector header) enables this to be correlated with 
> CDRs generated by other entities, and thus enable the 
> operator to generate a complete accounting of the call.
> 
> Therefore the MRFC is able to generate CDRs, as some of the 
> functions it performs may well add value.
> 
> > As per my understanding of IMS the MS (MRFC + MRFP) is capable of 
> > intelligence of generating CDR if required to do so.
> > 
> > MS should track all calls users which are bandwidth heavy e.g video 
> > calls.
> > Since AS is generally transparent to SDP (apart from version and 
> > sessionid) it can generate data only if it knows some call 
> identifier 
> > which is unique in the network for the call.
> > 
> > Though I am yet to see this sort of services being used but still 
> > theoretically it is possible as per IMS.
> > 
> > Roni,
> and MRFP 
> > (but I haven't seen any MS which does so). I also don't 
> expect MRFP to 
> > understand P-CHARGING-VECTOR but MRFC must have capability to 
> > understand the P-CHARGING-VECTOR and thereby generating 
> CDRs (as per 
> > the IMS at least).
> > 
> > 
> > Regards,
> > Rahul
> > 
> > 
> >  
> > 
> > If it is the MRFC separated from the AS (I am not sure 
> which protocol 
> > is
> > used) I would expect the Application Server to supply it like Eric 
> > said.
> > Roni Even
> > 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
>