Subject: [Sipping] Re: Update to 3pcc

From: David Schwartz <[email-masked]>
Date: Wed, 30 Jul 2003 11:10:45 +0300

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

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 30 Jul 2003 10:09:05 -0500

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 
> 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.
> >
> >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.
> >
> 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: Henry Sinnreich <[email-masked]>
Date: Wed, 30 Jul 2003 10:41:18 -0500

(Correction, sorry )This may turn out to be a very productive discussion.

> billing entity and REFER will not suffice.

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

The centralized controller is a soulmate of the B2BUA, and both have some
tremendous drawbacks compared to REFER:

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

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

Turns actually the ISP into some sort of large PBX. Is this a good idea on
the Internet? I add the above to  Jiri's and Jonathan's comments. 

I will take REFER any time instead. (Am actually not sure which is more
evil, the central controler AKA 'softswitch' or the B2BUA) 

Thanks, Henry