Subject: [Sip] draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations

From: "Francois Audet" <[email-masked]>
Date: Wed, 17 May 2006 16:16:26 -0500

Jonathan made a proposal that Contacts in registrations be automatically
"upgradable/downgradable" between sip and sips. 

His exact wording:
> I would propose that it is never 
> necessary to include separate contacts for sip and sips. If a 
> registration is sent such that each hop was over TLS (done by 
> having the 
> r-uri in the registration be a sips URI), then that contact (and the 
> associated secure path URI) can be used for requests sent to 
> sip or sips 
> AOR. If a request is sent to a SIPS AOR, the proxy sets the 
> r-uri to a 
> sips version of the contact. If a request is sent to a SIP AOR, the 
> r-uri is a sip version of the contact.

The draft I wrote actually takes the opposite approach.

It proposes that the UA always explicitely registers sip and sips
contacts
(in the same registration) in order to bind each one to the AOR. The AOR
itself 
however is "upgradable/downgradable" the same way Jonathan is saying.

It has the advantage that a UA can then specifically request to be
reachable
ONLY using a sips contact, ONLY using a sip contact, or BOTH (and
also specify q-value). It also allows to explicitely say if it is
reachable
with UDP (again, with a q-value). This could be very useful for a UA
that has
a policy of "always TLS, never TLS, either (TLS prefered), or either
(non-TLS
prefered). I don't think this is easily achievable with Jonathan's
proposal.

Other comments?

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 May 2006 18:11:32 -0400

> prefered). I don't think this is easily achievable with Jonathan's

I don't much like having to register multiple contacts. But in practice 
I doubt anyone will do so anyway. In practice I think a UA that supports 
SIPS will need -outbound- for the TLS connection (because it probably 
doesn't have a cert), so that connection will be present. There will 
then be little reason to have another path. So I don't find your 
proposal too burdensome.

A problem with Jonathan's proposal, and actually any proposal that 
upgrades or downgrades the scheme in a URI, is that it interacts poorly 
with a transport= uri parameter. I might want to use TLS for both SIP 
and SIPS calls.  Or I conceivably might want to allow UDP for SIP calls, 
while using TLS for SIPS calls. (I'm not sure that actually makes much 
sense.)

So I think I prefer Francois' version better, but I think Jonathan's 
could be tweaked to be fine. And I think the rules for upgrade/downgrade 
must be refined to take account of the transport parameter, and possibly 
other parameters. (maddr?)

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 18 May 2006 09:15:41 +0300

Francois Audet writes:

 > I don't think this is easily achievable with Jonathan's
 > proposal.

if sip ua accepts both sip and sips, there is no problem.  if it accepts
only one, it will give negative reply if you try with the other.  i
don't see where the problem is.

-- juha

 064A913F98A;
	Thu, 18 May 2006 09:15:42 +0300 (EEST)
Date: Thu, 18 May 2006 09:15:41 +0300
From: Juha Heinanen <[email-masked]>
To: "Francois Audet" <[email-masked]>
Subject: [Sip] draft-audet-sip-sips-guidelines: sip and sips contacts in
	Registrations
Cc: IETF SIP List <[email-masked]>

Francois Audet writes:

 > I don't think this is easily achievable with Jonathan's
 > proposal.

if sip ua accepts both sip and sips, there is no problem.  if it accepts
only one, it will give negative reply if you try with the other.  i
don't see where the problem is.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 May 2006 23:41:19 -0400

Francois Audet wrote:

> also specify q-value).

I'm questioning the need for that.

In this particular case, I think simplicity trumps features. I think it 
is an undue burden to require two contacts just to indicate something 
that should normally be permitted. I would think that in 99.9% of the 
cases, a UA would be willing to accept calls of eitheFrom [email-masked] Fri May 19 03:02:08 2006
Date: Thu, 18 May 2006 23:41:19 -0400
From: Jonathan Rosenberg <[email-masked]>
To: Francois Audet <[email-masked]>
Cc: IETF SIP List <[email-masked]>
Subject: [Sip] Re: draft-audet-sip-sips-guidelines: sip and sips contacts in
	Registrations

Francois Audet wrote:

> also specify q-value).

I'm questioning the need for that.

In this particular case, I think simplicity trumps features. I think it 
is an undue burden to require two contacts just to indicate something 
that should normally be permitted. I would think that in 99.9% of the 
cases, a UA would be willing to accept calls of either type. I can't see 
any case where it would only accept sip and not sips. I can imagine 
cases (secure phone service) where it would only accept sips. However, 
as Juha points out in his mail, it can simply reject an incoming call 
which was received over sip. All your proposal does is push that 
rejection into the network. For what benefit?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 19 May 2006 12:54:51 +0200

Francois,

Problem with multiple contacts: how do you prevent forking? note that 
q-order is not sufficient for that

To signal that a Contact URI should not be upgraded to SIPS, the UAC could 
use callee capabilities (RFC3840):

Contact: <sip:[email-masked]>;schemes="sip,!sips" (signals no 
upgrading)

Note that the reverse case ("sips,!sip") would make less sense, since the UA 
would be capable of "sip", just not willing. Better to leave this decision 
to the UA, on a per-call basis (it might reasonably decide this based on 
where/whom the call is coming from)

Regards,

Jeroen

PS I was expecting to find a callee capability to indicate supported 
transports, but there is none in RFC3840. Can anyone explain why?

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "Francois Audet" <[email-masked]>
Cc: "IETF SIP List" <[email-masked]>
Sent: Friday, May 19, 2006 5:41 AM
Subject: [Sip] Re: draft-audet-sip-sips-guidelines: sip and sips contacts 
inRegistrations

>> "upgradable/downgradable" between sip and sips. His exact wording:
>>
>>>I would propose that it is never necessary to include separate contacts 
>>>for sip and sips. If a registration is sent such that each hop was over 
>>>TLS (done by having the r-uri in the registration be a sips URI), then 
>>>that contact (and the associated secure path URI) can be used for 
>>>requests sent to sip or sips AOR. If a request is sent to a SIPS AOR, the 
>>>proxy sets the r-uri to a sips version of the contact. If a request is 
>>>sent to a SIP AOR, the r-uri is a sip version of the contact.
>>
>>
>> itself however is "upgradable/downgradable" the same way Jonathan is 
>> saying.
>>
> In this particular case, I think simplicity trumps features. I think it is 
> an undue burden to require two contacts just to indicate something that 
> should normally be permitted. I would think that in 99.9% of the cases, a 
> UA would be willing to accept calls of either type. I can't see any case 
> where it would only accept sip and not sips. I can imagine cases (secure 
> phone service) where it would only accept sips. However, as Juha points 
> out in his mail, it can simply reject an incoming call which was received 
> over sip. All your proposal does is push that rejection into the network. 
> For what benefit?
>
> -Jonathan R.
>
> --

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 May 2006 13:05:50 -0500

> > contacts (in the same registration) in order to bind each 
> one to the 
> > AOR. The AOR itself
> > reachable ONLY using a sips contact, ONLY using a sip 
> contact, or BOTH 
> > (and also specify q-value).
> 
> cases (secure phone service) where it would only accept sips. 
>
> However, 

Well, to me that's the issue.

The starting point today, is UAs that are deployed and don't support
TLS.

We want to start introducing UAs that now support TLS. We want to do
this
in a way that does not impact the network in an undue manner.

To me, having calls that fail because they are using the wrong transport
is
unacceptable. HERF could make a terminal unreachable completely for one
thing.
This would happen all the time...

Granted, in some cases (e.g., if an outbound proxy is used as in
SIP-outbound),
the outbound proxy has a good way of knowing the transport used by a
specific
UA. On the other hand, without an outbound proxy, it will be impossible.
It
gets even worst if a redirect server is used instead of a proxy.

I would venture to say that the burden of adding a contact for
transport=tls in 
Registration (compared to state of the art today) is relatively simple.
It is
much less of a burden then having calls fail all over the place because
one
expect sips instead of sip (or vice-versa).

Going back to the introduction of my first TLS UAs into the network...
How do
I switch from "try TCP (or UDP) first" to "try TLS first"? If I have
10,000 
terminals supporting TCP only, and I add my first TLS terminal, does it
mean that
essentially all call fails the first time? Or that it only fails for
calls to
the TLS terminal (prompting questions of why the TLS terminal has slow
setup
time).

But, I'm really not wed to a particular mechanism for indicating support
for
which transport.

I see 4 possibilities (thanks to Jeroen for pointing out RFC 3840):

1 - List multiple contacts, with q-values, using the form sip or sips.
Jeroen
    pointed out that it may overlap with the meaning of multiple
separate contacts
    used for forking, creating ambiguity. Also, meaning of sip vs sips
is 
    somewhat confusing in this case. (This is what is in my current
draft).

2 - List multiple contacts, with q-values as above, but using
;transport=tls
    instead of sips. Slighly less confusing that (1) perhaps, but still
has
    the forking ambiguity issue.

3 - Use RFC 3840 user agent capabilities "schemes" feature param for sip
& sips
    (including !sip and !sips if required). This implies "all the hops"
    as opposed to a single hop. Contrary to 1 and 2, it doesn't consist
of two
    contacts, it is one contact with 2 transport capabilities. 

4 - Define new RFC 3840 user agent capabilties for "transport" feature
param.
    Similar to 3, but would allow for distinguishing hop-by-hop behavior
from
    that last hop. 

Personnaly, I think options 3 and 4 are probably better than 1 or 2.
They
might aleviate both Jonathan and my concerns with other mechanisms.  I'm
not
decided on if I prefer 3 or 4. I have a slight preference for 4, because
3 could
be a little ambiguous. 4 would allow you to specify TLS on the last hop,
but
allow for both sip and sips end-to-end (useful for sip-outbound for
example).

Any opinions?
Jonathan?
Others?

---

From: Dean Willis <[email-masked]>
Date: Fri, 19 May 2006 19:00:06 -0500

On May 18, 2006, at 10:41 PM, Jonathan Rosenberg wrote:
> .
>
> In this particular case, I think simplicity trumps features. I  
> think it is an undue burden to require two contacts just to  
> indicate something that should normally be permitted. I would think  
> that in 99.9% of the cases, a UA would be willing to accept calls  
> of either type. I can't see any case where it would only accept sip  
> and not sips. I can imagine cases (secure phone service) where it  
> would only accept sips. However, as Juha points out in his mail, it  
> can simply reject an incoming call which was received over sip. All  
> your proposal does is push that rejection into the network. For  
> what benefit?
>

Let's be real. 3GPP IMS clients can't deal with SIPS. But their SIP  
comes over a link that is arguably as-well protected as SIPS.

--
Dean