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

From: Rohan Mahy <[email-masked]>
Date: Sat, 13 Sep 2003 08:10:40 -0700

Jonathan,

You continue to assume requirements which do not apply uniformly for  
all prepaid applications. While REFER might not work for your idea of a  
specific prepaid application, it works just fine for my personal  
favorite prepaid application.  I believe that presented with the choice  
of a 3pcc/B2BUA prepaid application vs. a REFER-based solution, many  
providers (especially the non-traditional ones) will pick the  
REFER-based solution.

thanks,
-rohan

On Wednesday, August 13, 2003, at 12:17 PM, Jonathan Rosenberg wrote:

> 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.
>
>
>
> Jiri Kuthan wrote:
>
>> 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
>
> -- 
> 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

_______________________________________________
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