Subject: Re: [MEDIACTRL] Query

From: Eric Burger <[email-masked]>
Date: Fri, 22 Feb 2008 10:08:06 -0500

[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

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 24 Feb 2008 08:54:25 +0200

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]
> 
> 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.

---

From: Rahul <[email-masked]>
Date: Mon, 25 Feb 2008 13:23:24 +0530

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

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 25 Feb 2008 10:00:01 +0200

Rahul

"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."

This is an important assumption. The question is if the AS just transfer the SDP as is or does it do some policy enforcement. Who decides on what BW is allowed for the conference. I think that currently we assume that it is the AS and not the MS.

Roni Even 

> From: Rahul [mailto:[email-masked]]
> Sent: Monday, February 25, 2008 9:53 AM
> To: Even, Roni; 'Eric Burger'
> Cc: [email-masked]
> haven't seen any MS which does so). I also don't expect MRFP to understand

---

From: [email-masked]
Date: Mon, 25 Feb 2008 10:15:57 +0100

Hi Rahul and Roni,

from my understanding of IMS, the idea is to have policies dealt with  
in the P-CSCF, whereas bandwidth management is one of the typical  
scenarios. If that's the case, the AS and MS get an already filtered  
SDP, and so should not take care of bandwidth tracking themselves.

L.

Quoting "Even, Roni" <[email-masked]>:

> 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."
>
> This is an important assumption. The question is if the AS just   
> transfer the SDP as is or does it do some policy enforcement. Who   
> decides on what BW is allowed for the conference. I think that   
> currently we assume that it is the AS and not the MS.
>
> Roni Even
>

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]
_______________________________________________
MEDIACTRL mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 25 Feb 2008 06:13:51 -0800

And, the unique session identifier is still the dialog identifier, which
the AS knows.  In fact, the AS knows it, and the MS does NOT know it.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Monday, February 25, 2008 3:00 AM
To: [email-masked]; Eric Burger
Cc: [email-masked]
Subject: RE: [MEDIACTRL] Query

Rahul

"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."

This is an important assumption. The question is if the AS just transfer
the SDP as is or does it do some policy enforcement. Who decides on what
BW is allowed for the conference. I think that currently we assume that
it is the AS and not the MS.

Roni Even 

>       I also don't expect the Media Server to generate calls. (aka 
> start sending INVITE on its own).
> sessionid)
> it can generate data only if it knows some call identifier which is 
> unique in the network for the call.
> 
> 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
> 
> 
> 
>

---

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

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 

> 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]
>       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.
> 
> 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,
> 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
> 
> 
>  
> 
> > From: [email-masked] 
> [mailto:[email-masked]] 
> > On Behalf Of Eric Burger
> > 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.
> > 
> > >       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]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl