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

From: Jiri Kuthan <[email-masked]>
Date: Thu, 07 Aug 2003 18:33:28 +0200

David,

ok, I must thave misunderstood your argument. So you are saying
prepaid providers need a b2bua for teardown anyhow, so why to 
bother about REFER? A quick answer is that in an open-service
model, there may be other parties than the prepaid provider and 
these parties may prefer a simple technology over b2bua. And
since REFER is technically better, I'm no way happy about calling
it BCP in IETF.

More details:
- c-t-d may be implemented somewhere completely else than
  prepaid is. For example, prepaid b2bua is in front of your gateway,
  C-T-D is an application at caller's PC. 
- Since the prepaid and ctd applications live somewhere else, there
  is no reason to dictate use of a b2bua mechanism for ctd.
  Caller simply prefers a simple utility over a B2BUA. 
- And since REFER is imho doing a better job for ctd (think for example
  about the ringing problem), there is no reason to call a B2BUA-based 
  construct BCP.

I'm not opposed to b2bua middlebox in general -- there are certainly
applications which are hard to achieve otherwise, prepaid one of them. 
What I'm saying is that a BCP should show examples which are really 
_Best_ Current Practices. That's simply not the case with b2bua/ctd.

-Jiri

At 08:17 AM 8/6/2003, David Schwartz wrote:
>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 

--
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

---

From: Amir Zmora <[email-masked]>
Date: Wed, 30 Jul 2003 18:57:57 +0300

I'm not sure the REFER option will solve everything. For example if a call
is connected via a pre paid system that connected the 2 parties with REFER
how will it now disconnect the call or play some warning message to the
caller if it is not actively participating in the call.
Regarding S/MIME - I don't know of too many implementations actually using
it today in real deployment. Many are using TLS and that should work OK with
the B2B.

Amir
-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2003 6:09 PM
To: 'David Schwartz'; [email-masked]
Subject: RE: [Sipping] Re: Update to 3pcc

This may turn out to be a very productive discussion. David Schwartz writes:

> 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.

There may be more attractive billing collecting alternatives: CDRs in the
gateways. If the calls are between two IP endpoints, flat rate is a good
option.

The centralized controller, AKA B2BUA, has however some tremendous drawbacks
compared to REFER:

- The B2BUA breaks the e2e trust model and security, such as S/MIME. How
many B2BUAs would one have to trust in an interdomain call?

- The B2BUA keeps state and customer information. If attacked, loss of
customer privacy can be a huge liability for the ISP. And an unending source
of spam (being criminalized soon by legislators) and telemarketing calls for
the unhappy users.

- Scalability, single point of failure, etc. 

Turns actually the ISP into some sort of large PBX. Is this a good idea on
the Internet? Add Jiri's and Jonathan's comments to the above. I will take
REFER any time instead. 

What do the people on the list think about this? If anyone cares...

Thanks, Henry

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of David Schwartz
> Sent: Wednesday, July 30, 2003 3:11 AM
> To: [email-masked]'
> Subject: [Sipping] Re: Update to 3pcc
> 
> 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
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Sipping digest..."
> 
> 
> Today's Topics:
> 
> 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-elwell-sipping-qsig2
> sip-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
> 
> 
> 
> 
> > 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?
> > 
> > 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
> 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. 
> 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.
> >
> 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.
> >
> 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 
> >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
> 
> --
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> End of Sipping Digest
> 
> 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:05:37 -0400

Sorry for the delay. Responses inline.

Paul Kyzivat wrote:

> I'm way behind in my mail and just discovered this discussion. Earlier I 
> had actually discovered the new draft and posted a question on this very 
> point without first finding this conversation. I apologize for that.
> 
> Could this problem not be dealt with in a backward compatible manner by 
> using a domain name that actually exists in the public DNS and resolves 
> to the address 0.0.0.0?

I'm not sure how this would work in practice. Who would own such a 
domain? Why would they agree to manage it in this way? I guess it 
would need to be some kind of public service, managed by IETF or 
something. I don't like the idea of tying the operation of the 
protocol to something like this.

> 
> I don't see how Jonathan's alternative helps in practice. The .invalid 
> address often is needed in an initial offer, so there has as yet been no 
> opportunity to exchange option tags. So in this case it would require 
> starting with a Require of the option, which will result in the request 
> failing, and the need to retry with 0.0.0.0 in that case. So everybody 
> needs to support both ways, and for awhile we get lots of extra 
> messaging incurred when somebody tries to do the right thing. Anybody in 
> their right mind is just going to start out using 0.0.0.0, because it is 
> more likely to work on the first try.

I agree this is a problem.

I don't really have a better solution. All I can say is that the only 
flow which has an initial offer with SDP of 0.0.0.0 is flow II, which 
is not one of the recommended flows. As such, much of the usages of 
0.0.0.0 will be for suspending streams post call setup, and those 
would not have this problem of extra RTT; the initial INVITE would 
indicated that .invalid is supported.

So, I'd propose to still go ahead and revert back to 0.0.0.0 with some 
caveats, and then submit a separate I-D on using .invalid.

-Jonathan R.

---

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Wed, 13 Aug 2003 17:39:53 -0400

Inline [RRR]

... 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.

[RRR] Right. The draft shows how to use the 3pcc, if one wants to do so.

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

[RRR] I agree.

-Jonathan R.