Subject: Re: [Sipping] Update to 3pcc

From: Jiri Kuthan <[email-masked]>
Date: Mon, 28 Jul 2003 10:17:51 +0200

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jul 2003 13:45:36 -0400

Jiri,

REFER is tempting as an alternative to a b2bua for click-to-dial, but I 
suspect there are practical difficulties to its use. The details may 
vary depending on how you imagine using it.

The simplest approach is presumably to have the click-to-dial server 
simply send a REFER to one party, refering them to the other party. 
Issues with this:

- the referred endpoint probably needs to alert its user and await an 
answer before ending the invite. Such behavior isn't standardized, and 
its likely that many/most UAs don't do this.

- in cases where billing is involved, somebody is going to be billed for 
the call. It isn't clear how you can build a click-to-dial server so 
that the "right" thing happens, whatever that is.

- in general, authorization for such a REFER isn't likely to be granted 
to just anybody. While it may be possible to set up a specific 
arrangement for this between the click-to-dial server and the referee, 
that would require some propriatary work.

I suppose another way to handle this would be to have the click-to-dial 
server send an invite to the referee, either medialess or with media 
black-holed. Then it could send a refer within that dialog. This would 
resolve the alerting issue, and transform the other issues into familiar 
ones having to do with transfer. Issues with this:

- afaik billing and authorization issues for refer aren't fully solved.

- if this approach is done with black hole media then it has the same 
problems you were hoping to avoid.

I think the b2bua approach to click-to-dial has the best chance of 
working. This is more likely if 0.0.0.0 is used as the black-hole 
address. It is less likely if .invalid is used as the black-hole address.

	Paul

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 29 Jul 2003 12:13:49 +0200

At 07:45 PM 7/28/2003, Paul Kyzivat wrote:
>Jiri,
>
>REFER is tempting as an alternative to a b2bua for click-to-dial, but I suspect there are practical difficulties to its use.

Paul, 

I'm glad you raised the practicability issue -- you may want to learn that REFER-based 
click-to-dial works even with your company's SIP phones. Feel free to subscribe to
iptel.org, use web-based phonebook and watch SIP signaling. The phonebook uses REFER 
for c-t-d. Running code available at our site. That's it.

The essential argument however is arhictectural. REFER c-t-d doesn't take a "middlebox" 
b2bua whose use has severe architectural limitations, see me previous email. More replies
to your comments follow inline -- I think most of confusion comes from lack of distinction
between user interface and protocol aspects.

Thanks,

-Jiri

> The details may vary depending on how you imagine using it.
>
>The simplest approach is presumably to have the click-to-dial server simply send a REFER to one party, refering them to the other party. Issues with this:
>
>- the referred endpoint probably needs to alert its user and await an answer before ending the invite. Such behavior isn't standardized, and its likely that many/most UAs don't do this.

Well, that's been IETF way of doing things -- product features are not standardized,
protocols are. REFER protocol specification explicitly legalizes out-of-dialog use and 
there are more uses coming for it (conferencing, for example). Device's policy for 
dealing with such requests is a product feature. Alerting a user seems like a perfectly 
reasonable user-interface design choice but again: that's out of scope of protocol 
specification.

I agree phones accepting out-of-dialog REFERs are hard to find if there are any at all.
That's very likely to change as the apps come in. We use in the meantime a hack:
our CTD wraps the REFER in a dummy call with no media. (I don't want to make advertising
to brave SIP phone companies but let me name at least few examples which are known
to work: cisco, mitel, pingtel, grandstream).

>- in cases where billing is involved, somebody is going to be billed for the call. It isn't clear how you can build a click-to-dial server so that the "right" thing happens, whatever that is.

I don't understand this sentence -- perhaps you want to explain what "right thing" means
and what the compelling problem is.

>- in general, authorization for such a REFER isn't likely to be granted to just anybody. While it may be possible to set up a specific arrangement for this between the click-to-dial server and the referee, that would require some propriatary work.

Like above: product features are out-of-scope. My user-interface preference is it is all
very much like processing of unsolicited incoming calls. A telephone may prompt its
user if an INVITE or REFER or perhaps even FOOBAR comes in. It may alert, flesh, open up
a window, vibrate, yell, whatsoever. Other telephones may accept any or no REFERs but 
I wouldn't buy such.

>I suppose another way to handle this would be to have the click-to-dial server send an invite to the referee, either medialess or with media black-holed. Then it could send a refer within that dialog. This would resolve the alerting issue, and transform the other issues into familiar ones having to do with transfer. Issues with this:

Yes, that's what we do now. I think it is rather a temporary hack for now, but I like
it still better than B2BUA. (Temporary hack with long-term plan over misconcepted architecture.)

>- afaik billing and authorization issues for refer aren't fully solved.

I can't comment as I don't know what the billing and authorization issues are.

>- if this approach is done with black hole media then it has the same problems you were hoping to avoid.

That's true but as said, the INVITE wrapper is imho a temporary hack.

>I think the b2bua approach to click-to-dial has the best chance of working. This is more likely if 0.0.0.0 is used as the black-hole address. It is less likely if .invalid is used as the black-hole address.

Hard-to-agree: running code for refer-based ctd is outthere and it does not suffer
from b2bua's architectural shortcomings.

--

>>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
>>>-- Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza