Subject: RE: [Sipping] Re: Update to 3pcc

From: David Schwartz <[email-masked]>
Date: Wed, 6 Aug 2003 09:17:00 +0300

Hi Jiri.

I was referring specifically to the call teardown issue associated with most
pre-paid billing models. 

David

-----Original Message-----
From: Jiri Kuthan [mailto:[email-masked]]
Sent: Tue, August 05, 2003 7:39 PM
To: David Schwartz; [email-masked]'
Subject: Re: [Sipping] Re: Update to 3pcc

Hello David,

I don't see how billing servers are related to method of 
call initiation.

Actually I believe that how a call is initiated (by manual
dialing a destination, by REFER-based click-to-dial, by b2bua-based
click-to-dial, CTI, etc.) is completely orthogonal to how the 
call is charged for. Regardless what charging system you use 
(if any), there will be different methods for initiating calls, 
some will be better off than others. I maintain that a click-to-dial 
b2bua is not a BCP.

-jiri

At 10:10 AM 7/30/2003, David Schwartz wrote:
>Hi Jiri
>
>REFER is good solution if you assume that either there are no billing
>issues, or alternatively, that the endpoint/s handle the billing issues. If
>this is not the case, for example, in an application where a centralized
>controller is setting up a call to two PSTN numbers, then you will need a
>centralized billing entity and REFER will not suffice.
>
>David
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Mon, July 28, 2003 7:00 PM
>To: [email-masked]
>Subject: Sipping digest, Vol 1 #1144 - 2 msgs
>
>
>Send Sipping mailing list submissions to
>        [email-masked]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>        https://www1.ietf.org/mailman/listinfo/sipping
>or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
>You can reach the person managing the list at
>        [email-masked]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Sipping digest..."
>
>
>Today's Topics:
>
>   1. Re: Diversion header (Cullen Jennings)
>   2. Re: Update to 3pcc (Jiri Kuthan)
>
>--__--__--
>
>Message: 1
>Date: Sun, 27 Jul 2003 19:05:10 -0700
>Subject: Re: [Sipping] Diversion header
>From: Cullen Jennings <[email-masked]>
>To: Romel Khan <[email-masked]>, <[email-masked]>
>
>
>I assume your question is there some way for  for the final destination
that
>receives the call to know the who the 1st callee was that had some device
in
>the network redirect the call elsewhere.
>
>The answer is YES - there has been a lot of confusion over this so think
>about my answer carefully - it will seem counter intuitive at first. The
>answer is the "To" header but it will take me a second to explain why.
>
>Imagine case 1 where A send a call to proxy B,  that sent to to C. Now C
>sent a 302 back B and B then forked the call to D. The To header in the
>message D receives will still have the To set to C. C is the element that
>sent the first 302.
>
>Now imagine a case (like your question) where there is not a recursive
>proxy. The 302 will go all the way back to A. Now A forms a new invite to
>but it can leave the To header set to the same thing it was in the original
>message (C in this case). When the message arrives at D, the To header will
>be set to C.
>
>If D was a voice mail system, it might be able to know to act on behalf of
C
>instead of some other entity.
>
>There are more complex things that relate to your request. Mary Barnes has
>been moving the history work along
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-history-04.txt
>
>There is some work on QSIG mappings with diversion
>http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-diversion
-
>00.txt
>
>There is a draft-levy-sip-diversion which I (and many others) believe has a
>pretty much zero chance of being accepted or becoming a RFC. This work has
>been superceded by the history work. Quite a few people do not support the
>history work and it is moving very slowly. Don't expect any of this to
>resolve quickly.
>
>Give some careful thought to if the "To" header meets your needs and if it
>does use - The To header is widely implemented :-)
>
>
>Cullen
>
>
>
>
>On 7/21/03 8:55, "Romel Khan" <[email-masked]> wrote:
>
>> Is there any SIP header defined in any SIP RFC or Internet Draft that can
>> include the address of the 1st callee, who redirected the call using 302,
>in
>> the 2nd outgoing INVITE?
>> 
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [email-masked] for questions on current sip
>> Use [email-masked] for new developments of core SIP
>> 
>
>
>
>--__--__--
>
>Message: 2
>Date: Mon, 28 Jul 2003 10:17:51 +0200
>To: Jonathan Rosenberg <[email-masked]>, sipping
<[email-masked]>
>From: Jiri Kuthan <[email-masked]>
>Subject: Re: [Sipping] Update to 3pcc
>
>I'm actually not convinced that it is proper to show click-to-dial
>as a motivating example for use of b2bua and label it BCP.
>
>Use of REFER seems technically a superior solution worth being called
>BCP. Roots of the advantages are in a better application of e2e principle. 
>REFER takes no middle-box b2bua -- it delegates signaling to end-points.
>Advantages include:
>- All the pitfalls with media are so straigforward, they don't even 
>  need to be described (like now in sessions 8 and 9).  
>- It takes no media server to transmit ringing tone. 
>- There are no SDP compatibility issues on controller's side.
>
>-jiri
>
>At 07:51 PM 7/8/2003, Jonathan Rosenberg wrote:
>>Folks,
>>
>>You may have noticed that I posted an update to the 3pcc spec:
>>
>>http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.txt
>>http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.html
>>http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-04.txt
>>
>>The update is based on comments received from IESG while reviewing the
>draft. In particular, there were problems with the usage of 0.0.0.0 to
>imply that no media nor RTCP should be sent. This IP address is not meant
>for that purpose. Rather, the .invalid TLD is much better suited. So, I
>changed the draft to make use of .invalid in flows where the controller
>doesnt want media to be sent.
>>
>>Now, there are some concerns with that which folks need to be aware of:
>>
>>1. It is at odds with RFC 3264, which actually recommends 0.0.0.0. In
fact,
>the problem is really with RFC 3264, NOT 3pcc. However, 3264 is done, and
>this one isnt. I logged a bug against RFC 3264 on this, and we'll need to
>work on a way to transition folks towards using .invalid and not 0.0.0.0.
>>
>>2. One the premises of 3pcc is that it should be compatible with any UA
>that is RFC 3261 compliant. If a controller uses .invalid in the SDP, I am
>not sure what a SIP endpoint would do. I don't believe anything in RFC 3264
>or in SIP talks about handling the case where there is an issue with a
>domain name in the SDP. As such, if you use .invalid, there could be
interop
>problems. The document mentions this.
>>
>>Comments or questions welcome.
>>
>>Thanks,
>>Jonathan R.
>>-- 
>>Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>>Chief Technology Officer                    Parsippany, NJ 07054-2711
>>dynamicsoft
>>[email-masked]                     FAX:   (973) 952-5050
>>http://www.jdrosen.net                     PHONE: (973) 952-5000
>>http://www.dynamicsoft.com
>>
>>
>>
>>_______________________________________________
>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>This list is for NEW development of the application of SIP
>>Use [email-masked] for questions on current sip
>>Use [email-masked] for new developments of core SIP
>
>--
>Jiri Kuthan            http://iptel.org/~jiri/  
>
>
>
>
>--__--__--
>
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments of core SIP
>
>End of Sipping Digest
>
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments of core SIP 

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

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 12 Aug 2003 16:12:22 -0700

Hi David,

I think it is completely reasonable to build a pre-paid calling system  
using a proxy with AAA and session timer and optionally a cooperating  
UA (for IVR features).

If a click-to-dial application sends a REFER to my phone which is using  
a pre-paid PSTN gateway service, there is no reason that the gateway  
service needs to use a B2BUA.  Instead, a proxy can use the session  
timer extension when proxying the call for a portion of the user's  
available time.

However, even if the PSTN gateway service decided to use a B2BUA for  
its prepaid service, this is no reason the click-to-dial application  
(possibly from a completely different organization) needs to use 3pcc.   
The two should be disconnected.

thanks,
-rohan

---

From: Dean Willis <[email-masked]>
Date: 13 Aug 2003 10:13:48 -0500

> using a proxy with AAA and session timer and optionally a cooperating  

Just as billing from session-timer is not a use case, neither is prepaid
control using session timer appropriate. We designed session-timer to
have a resolution on the order of minutes or hours, not seconds. It's
for cleaning up state when stuff goes wrong -- basically, a soft-crash
mechanism. One doesn't drive a car by manipulating its air-bags or
discard the brakes because one's seat belt is buckled.

It sounds to me like you're introducing a time-bounded variant of the
authorization-token header. Something like that COULD be used by a
cooperating UA (say, the PSTN gateway) with reasonable success.

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 13 Aug 2003 15:17:11 -0700

On Wednesday, August 13, 2003, at 08:13 AM, Dean Willis wrote:

> have a resolution on the order of minutes or hours, not seconds.

In many prepaid applications that is all that is required. For example:

UA sends an INVITE with apropos credentials.
Proxy does a AAA lookup, finds out there is enough credit for 2 hours, 
sets session timer at 15 minutes and proxies the request to a gateway 
with Require: timer.
After 30 minutes the gateway reINVITEs (a timer refresh request).  The 
Proxy again does a AAA lookup.  At this point there is only enough 
credit for 10 minutes (the caller used the prepaid service to make a 
more expensive call). The proxy forwards the request with session timer 
set to 5 minutes.
On the next timer refresh, the proxy forwards the request with a 3 
minute timer.  Finally the proxy uses a 2 minute timer.  When the last 
timer refresh arrives, the Proxy sends a 403, and the gateway tears 
down the session.

This mechanism works very well and is perfectly appropriate if either 
only one session is allowed at a time, or if you are willing to reserve 
resources for an existing session for a few minutes in the future.

> It's for cleaning up state when stuff goes wrong -- basically, a 
> soft-crash
> mechanism.

I have no problem with that.  But it is a perfectly reasonable solution 
for some prepaid applications (not all of them obviously), and requires 
no changes to the session timer spec.

thanks,
-rohan

> One doesn't drive a car by manipulating its air-bags or

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Aug 2003 11:50:10 -0400

I agree with Dean that this is not at all what session timer was meant 
for. The spec is pretty explicit about its usage as a cleanup mechanism.

You'll have serious problems if the refreshing side is not trusted. 
Session timer allows either side to refresh. So, if this is a PC to 
phone case and PC is refreshing this won't work.

Even when its the gateway refreshing, 403 doesnt cause the gateway to 
terminate the call - at least it shouldnt, I dont think. Nothing in 
the spec says to tear down the call if you get a 403 to an INVITE.

-Jonathan R.

Rohan Mahy wrote:

> timer refresh arrives, the Proxy sends a 403, and the gateway tears down 
> the session.
>

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 15 Aug 2003 10:53:32 -0700

> for. The spec is pretty explicit about its usage as a cleanup 

if it works without changes to the existing mechanism, then what is the 
problem?

> phone case and PC is refreshing this won't work.

the gateway is the refresher, and is trusted.  the example i gave 
nicely fits a business model where the provider accounts for PSTN 
usage, but does not charge/account for arbitrary SIP sessions.   Easy 
things should be easy, contrived things will be hard and will require a 
B2BUA.

> the spec says to tear down the call if you get a 403 to an INVITE.

you are correct, but the call will be torn down after the session 
expires.  since the session is not refreshed when the proxy responds 
with a 403, the session will expire and the gateway will send a BYE.

thanks,
-rohan

>> Proxy does a AAA lookup, finds out there is enough credit for 2 
>> hours, sets session timer at 15 minutes and proxies the request to a 
>> gateway with Require: timer.
>> After 30 minutes the gateway reINVITEs (a timer refresh request).  
>> The Proxy again does a AAA lookup.  At this point there is only 
>> enough credit for 10 minutes (the caller used the prepaid service to 
>> make a more expensive call). The proxy forwards the request with 
>> session timer set to 5 minutes.
>> minute timer.  Finally the proxy uses a 2 minute timer.  When the 
>> last timer refresh arrives, the Proxy sends a 403, and the gateway 
>> tears down the session.
>> only one session is allowed at a time, or if you are willing to 
>> reserve resources for an existing session for a few minutes in the 
>> future.
>> I have no problem with that.  But it is a perfectly reasonable 
>> solution for some prepaid applications (not all of them obviously), 
>> and requires no changes to the session timer spec.
>> thanks,
>> -rohan

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 22 Aug 2003 03:21:39 +0200

That's it, thanks Rohan. If there is an element in the scenario (gateway), which 
provides a valuable service (P$S$T$N), then it implements session timer to protect 
itself (to cut-off a call). Elements that don't provide a service may not support 
timer, who cares.

-jiri

At 07:53 PM 8/15/2003, Rohan Mahy wrote:

>>I agree with Dean that this is not at all what session timer was meant for. The spec is pretty explicit about its usage as a cleanup mechanism.
>
>if it works without changes to the existing mechanism, then what is the problem?
>
>>You'll have serious problems if the refreshing side is not trusted. Session timer allows either side to refresh. So, if this is a PC to phone case and PC is refreshing this won't work.
>
>the gateway is the refresher, and is trusted.  the example i gave nicely fits a business model where the provider accounts for PSTN usage, but does not charge/account for arbitrary SIP sessions.   Easy things should be easy, contrived things will be hard and will require a B2BUA.
>
>>Even when its the gateway refreshing, 403 doesnt cause the gateway to terminate the call - at least it shouldnt, I dont think. Nothing in the spec says to tear down the call if you get a 403 to an INVITE.
>
>you are correct, but the call will be torn down after the session expires.  since the session is not refreshed when the proxy responds with a 403, the session will expire and the gateway will send a BYE.
>
>thanks,