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

From: Jiri Kuthan <[email-masked]>
Date: Tue, 05 Aug 2003 18:39:22 +0200

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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Aug 2003 15:17:52 -0400

Sorry for taking so long to weigh in here.

To address the specific billing issue, the problem is that, in fact, 
there ARE cases where the call is charged for differently if it was 
initiated as a result of click-to-dial. The user that makes the 
initial INVITE may not be the one that needs to be charged. There may 
be ways around that for REFER by having the INVITE carry some kind of 
special billing tokens or something (such tokens being pushed to the 
user in the Refer-To), but these then require the c2d provider and the 
caller to utilize the same provider. The 3pcc mechanism does not have 
this constraint.

However, in my mind, the real issue is one of control. 3pcc is useful 
in applications where the server needs to be in the signaling path in 
order to do or modify things. Thats not the case for all applications, 
but its true for many. Prepaid is one we have discussed as well. REFER 
just doesnt work there.

I'd also point out that the 3pcc spec is not saying that the best 
practice for c2d is to use 3pcc; it saying that if you want to do 
third party call control, here is how you do it.

I don't disagree that 3pcc for c2d can be complicated, and REFER does 
have a better story in terms of the media story. However, other work 
going on, namely the app interaction work, does address some of the 
big issues there in a pretty elegant way, I think.

You do raise a valid concern about security. The story there could 
definitely be better. I've been considering, for some time, writing 
down some requirements for a standards-based 3pcc mechanism (as 
opposed to a practice for using current mechanisms) that would do a 
few things just a little differently to achieve much better properties 
overall. In particular, note how flow I has a nice property that the 
b2bua doesnt actually need to touch the SDP - it can, therefore, flow 
e2e even if its encrypted. Flow I has other problems that prevent it 
from being used generally. Some actual SIP extensions could be used to 
rectify that.

However, this is our best current practice for doing 3pcc with what we 
have, and so we are constrained by 3261.

-Jonathan R.

---

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

At 09:17 PM 8/13/2003, Jonathan Rosenberg wrote:
>To address the specific billing issue, the problem is that, in fact, there ARE cases where the call is charged for differently if it was initiated as a result of click-to-dial. The user that makes the initial INVITE may not be the one that needs to be charged. There may be ways around that for REFER by having the INVITE carry some kind of special billing tokens or something (such tokens being pushed to the user in the Refer-To), but these then require the c2d provider and the caller to utilize the same provider. The 3pcc mechanism does not have this constraint.

I would prefer focusing on a common case. I really do not think 3-rd party billing 
for click-to-dial is something very usual. If you think so, then that's the example which
should come in the 3pcc draft.

>However, in my mind, the real issue is one of control. 3pcc is useful in applications where the server needs to be in the signaling path in order to do or modify things. Thats not the case for all applications, but its true for many. Prepaid is one we have discussed as well. REFER just doesnt work there.

I almost agree, but that's a different topic than I raised.

>I'd also point out that the 3pcc spec is not saying that the best practice for c2d is to use 3pcc; it saying that if you want to do third party call control, here is how you do it.

Sometimes, BCP for a technology is not to use it. I don't think IETF should document  
"BCP for 3pcc" on examples which are better implemented with another technology. 
If you are enthusiastic about HTTP, publish "BCP for Use of HTTP" and show examples 
of using HTTP to control media gateways, some people will not be happy either (unless 
it was April 1st). 

>I don't disagree that 3pcc for c2d can be complicated, and REFER does have a better story in terms of the media story. However, other work going on, namely the app interaction work, does address some of the big issues there in a pretty elegant way, I think.

I really prefer keeping simple things simple. One could of course build click-to-dial
even using VoiceXML-driven MGCP-enabled Softswitch, but that's not the goal. REFER
is simple and its purpose perfectly fits the c-t-d app.

-Jiri

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 22 Aug 2003 11:28:52 -0500

Where are the service providers in this discussion on billing?  ;-)

Thanks, Henry

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jiri Kuthan
> Sent: Thursday, August 21, 2003 9:22 PM
> To: Jonathan Rosenberg
> Cc: David Schwartz; [email-masked]'
> Subject: Re: [Sipping] Re: Update to 3pcc
> 
> initiated as a result of click-to-dial. The user that makes the initial
> INVITE may not be the one that needs to be charged. There may be ways
> around that for REFER by having the INVITE carry some kind of special
> billing tokens or something (such tokens being pushed to the user in the
> Refer-To), but these then require the c2d provider and the caller to
> utilize the same provider. The 3pcc mechanism does not have this
> constraint.
> 
> >However, in my mind, the real issue is one of control. 3pcc is useful in
> applications where the server needs to be in the signaling path in order
> to do or modify things. Thats not the case for all applications, but its
> true for many. Prepaid is one we have discussed as well. REFER just doesnt
> work there.
> 
> practice for c2d is to use 3pcc; it saying that if you want to do third
> party call control, here is how you do it.
> 
> have a better story in terms of the media story. However, other work going
> on, namely the app interaction work, does address some of the big issues
> there in a pretty elegant way, I think.
>

---

From: Kumiko Ono <[email-masked]>
Date: Wed, 27 Aug 2003 10:22:31 +0900

I think that click-to-dial service providers are usually different
from PSTN gateway provider. The settlement between these providers
is usually done monthly.

In this case, click-to-dial provider that also provides pre-paid 
calling service might want to take the initiative in disconnect procedure 
like sending BYE request.

Thanks,
Kumiko Ono