Subject: [Sipping-tispan] AoC requirements

From: "Bemmel, Jeroen van (Jeroen)" <[email-masked]>
Date: Mon, 5 Sep 2005 17:19:04 +0200

What about the ability to request advice of charge without actually engaging in communications? So a potential caller could inquire "How much would it cost if I were to call this person using this and that session characteristics"
 
Regards,
 
Jeroen
_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Sep 2005 14:16:07 +0100

This was always regarded as out of the scope of any of the PSTN/ISDN service definitions. 
 
In ISDN it would have been possible to deliver a charge value outside the existence of a call, but operators decided that it was possible to promise a price for a particular call, and then actually deliver at that price. Things like too many factors to take into account and so on. 
 
In that the simulation services are based on equivalent ISDN/PSTN services, it has therefore not been included in the requirements to SIPPING.
 
regards
 
Keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Bemmel, Jeroen van (Jeroen)
Sent: 05 September 2005 16:19
To: [email-masked]'
Subject: [Sipping-tispan] AoC requirements

Regards,
 
Jeroen

---

From: "Schmidt, Christian" <[email-masked]>
Date: Thu, 8 Sep 2005 09:47:54 +0200

Hi Miguel,

some more comments / proposals inline.

Regards,
Christian

> - AOC-3: This section gives the impression, that the changing
> cumultative charging values are not reported to the user.

I see your point. What about if the first sentence if reworded to say:

    The information supplied to the user is asynchronously generated,
    updated and reported to the user when new charging information is
    available.

Christian: That not really hits the point. What about an extension of
the
example?

    For example, when the cumultative charging value changes more then a
    certain predefined value; or, as time passes by, the charging 
    implications might change; or a re-INVITE can request new media 
    streams that will impact charging.

> 
> Questions:
> - Do we need a requirement for limiting the rate for this
asynchronously
> charging messages?

I don't know, perhaps someone else can comment this one. In my opinion 
it would a "nice-to-have" feature.

> - Do we need a requirement that the user can stop further
transmissions?

Another good point. I don't know, but I also think it would be nice to
have.

Christian: This could be described in Non-Requirements or perhaps as 
possible extensions. What do you think about this?

     A rate limitation for asynchronously charging messages is not
requested.
     The possibililty for a user to stop further delivery asynchronously
charging messages
     during a call is not requested.