Subject: RE: [Sip] changes in session timer

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Mar 2004 21:05:05 -0500

I was not suggesting that timeouts in the SIP layer had
anything to do with what may, or may not be going on
in the media layer.  I was suggesting that if a session
(at the SIP layer) went awry, then it would eventually
be torn down.  The speed at which you can detect 
the problem, and how long it takes before you do 
tear it down AFFECTS billing.  

Keith may be correct; it may be out of scope to discuss
how the timeouts affect billing.  It's a reality
however.

Brian

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, March 01, 2004 8:30 PM
> To: Drage, Keith (Keith)
> Cc: 'Rosen, Brian'; 'Jonathan Rosenberg'; [email-masked]'
> Subject: Re: [Sip] changes in session timer
> 
> 
> Drage, Keith (Keith) wrote:
> 
> > Is charging considerations within the requirements for 
> session timer.
> > 
> > There was considerable discussion of this issue a couple of 
> years back, and I thought that the charging use case was 
> eliminated from the requirements at that time.
> > 
> 
> I'd like to respond with a complete lack of political consdieration 
> here, so I'm sorry if you're offended.
> 
> Is billing in scope for Session Timer? In my humble opinion: 
> "No, Hell 
> no, and what part of no did you not understand?"
> 
> I believe that billing off the SIP signaling is a profoundly 
> bad idea. 
> Accurate billing has to be closer to the bearer path.
> 
> I think perhaps that Brian is suggesting that timeouts at the 
> SIP layer 
> can be used to detect failures that affect the media path, or 
> at least 
> failures for which there is no media path. While technically true, I 
> don't find the mechanism appropriate.
> 
> Suggestions:
> 
> 1) The media path is assumed to have real time delivery requirements. 
> Real-time is always going to be more accurate than the non-real-time 
> signaling path. If you need real-time billing, derive it from the 
> real-time media path.
> 
> 2) If there is no real-time media path, I can't imagine what 
> time-sensitive service is being consumed that requires real-time 
> accuracy in  accounting for. If you THINK you need real-time tracking 
> here, then perhaps a media channel that does NOTHING but report 
> connectivity for billing purposes is appropriate.
> 
> --
> Dean
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Tue, 2 Mar 2004 05:31:25 +0100

[session timer and billing]
I agree with Dean that accurate billing is better done one the media
level. However, in
some cases you want to pay for a service that is provided by someone you
don't
have a business relationship with. Let's say, your Korean translation
services charges you
for 3 hours of service while you did only use it  for 10 minutes. With
session timer, the proxy
might function as a trusted third party that logs the re-INVITEs. It's a
rudimentary non-repudiation
service. It does not prevent the translation service from charging you
accurately by the second. 
It might help to settle disputes.

A trusted third party in the media path is much uglier than session
timer.

Wolfgang

---

From: "Bender, Andrew" <[email-masked]>
Date: Sun, 7 Mar 2004 23:39:43 -0500

From a spiritual standpoint, I also have to disagree with the idea of arbitrarily limiting Min-SE to some "high" value if the motivation is an attempt to police or discourage misuse. 
 
I can attest that there are still practical deployments of session-timer that are used more for supervision of control-plane or session liveness than clearing of stale state; in most cases, this is a conscious exchange between scale and resolution. Although I'm not thrilled by this idea either, mandating 90s. (or anything else, really) seems to me like unnecessary machinery to save us from a problem that is not yet imminent. 

On the matter of billing; I hope not to rekindle a well traveled debate, but I'd like to invoke a comparison with the traditional circuit switched / wireline world. There really isn't a precedent for any sort of end-to-end bearer supervision in this realm, at least since the advent of CCS signaling schemes for digital trunks. A large proportion of the world's business oriented voice calling is now CCS all the way, and here, the state of bearer will be completely implicit. In these cases the "connect time", as it would be used for billing purposes, is inferred from some state transition in call signaling... where sip would be (is?) used in these applications, and without widespread use of RTCP (et al) the same would have to be true. 

Our experiences suggest that the sensitivities of carriers / users regarding resolution of "connect time" seems to be in the range of 5s - 60s depending on the network in question.

Regards,
Andrew Bender
taqua.com

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Monday, March 01, 2004 8:30 PM
To: Drage, Keith (Keith)
Cc: 'Rosen, Brian'; 'Jonathan Rosenberg'; [email-masked]'
Subject: Re: [Sip] changes in session timer

Drage, Keith (Keith) wrote:

> Is charging considerations within the requirements for session timer.
> 
> There was considerable discussion of this issue a couple of years back, and I thought that the charging use case was eliminated from the requirements at that time.
> 

Is billing in scope for Session Timer? In my humble opinion: "No, Hell 
no, and what part of no did you not understand?"

I believe that billing off the SIP signaling is a profoundly bad idea. 
Accurate billing has to be closer to the bearer path.

I think perhaps that Brian is suggesting that timeouts at the SIP layer 
can be used to detect failures that affect the media path, or at least 
failures for which there is no media path. While technically true, I 
don't find the mechanism appropriate.

Suggestions:

--
Dean

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Mar 2004 10:42:19 -0500

Once again, let me state that I don't see Session Timer as
directly used for billing, nor do I see ANY sip mechanism
directly used for billing.  I do think that the world is not
perfect, things go wrong, and sometimes sessions will be torn
down when there is a failure in the SIP level.  Session Timer
is one of the mechanisms that can be used to detect a failure
of the SIP layer.  When a session is torn down, billing is
affected.  The minimum time to detect a failure is reflected
in a time period where the user may or may not have a connection,
but is being billed for it.  Having a 90 second period is
a pretty long time if you are paying for it in 6 second
increments.  That's the ONLY implication I make between
session timer and billing.

Brian

> From: Bender, Andrew [mailto:[email-masked]]
> Sent: Sunday, March 07, 2004 11:40 PM
> To: Dean Willis; Drage, Keith (Keith)
> Cc: Rosen, Brian; Jonathan Rosenberg; [email-masked]
> Subject: RE: [Sip] changes in session timer
> 
> 
> From a spiritual standpoint, I also have to disagree with the 
> idea of arbitrarily limiting Min-SE to some "high" value if 
> the motivation is an attempt to police or discourage misuse. 
>  
> I can attest that there are still practical deployments of 
> session-timer that are used more for supervision of 
> control-plane or session liveness than clearing of stale 
> state; in most cases, this is a conscious exchange between 
> scale and resolution. Although I'm not thrilled by this idea 
> either, mandating 90s. (or anything else, really) seems to me 
> like unnecessary machinery to save us from a problem that is 
> not yet imminent. 
> 
> On the matter of billing; I hope not to rekindle a well 
> traveled debate, but I'd like to invoke a comparison with the 
> traditional circuit switched / wireline world. There really 
> isn't a precedent for any sort of end-to-end bearer 
> supervision in this realm, at least since the advent of CCS 
> signaling schemes for digital trunks. A large proportion of 
> the world's business oriented voice calling is now CCS all 
> the way, and here, the state of bearer will be completely 
> implicit. In these cases the "connect time", as it would be 
> used for billing purposes, is inferred from some state 
> transition in call signaling... where sip would be (is?) used 
> in these applications, and without widespread use of RTCP (et 
> al) the same would have to be true. 
> 
> Our experiences suggest that the sensitivities of carriers / 
> users regarding resolution of "connect time" seems to be in 
> the range of 5s - 60s depending on the network in question.
> 
> Regards,
> Andrew Bender
> taqua.com
>