Subject: [Sip] outbound: summary of issues

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 29 Mar 2006 20:49:21 +0200

An attempt to summarize issues identified so far, in the form of closed questions:

1. Configuration of outbound proxies - desire to avoid manual configuration at the UAC. Do we agree that we want this?
1a If yes, in the outbound draft or as a separate draft?
2. Detection of outbound/keepalive support - desire for dynamic discovery of support instead of (or perhaps in addition to) static configuration (the current keepalive=stun flag). Do we agree that we want this? (several options have been discussed)
3. Deployment scenarios - do we want to support:
 3a NAT between the edge proxy and the registrar (or more general: NAT beyond the first hop)
 3b UAC - edge proxy - registrar where the edge proxy adds Path but does not support outbound/keep-alive
 3c UAC - edge proxy - registrar where the edge proxy does not support/add Path (i.e. it drops out)

In addition, there is ongoing (and seemingly endless) discussion on STUN for TCP, which can be split into
4. Do we mandate only STUN (+ OS keepalive where available), or do we allow other alternatives?
5. Do we select / document other (primary) mechanisms? { PING, OPTIONS, other }

Regards,

jeroen

_______________________________________________
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: "Bob Penfield" <[email-masked]>
Date: Wed, 29 Mar 2006 15:48:38 -0500

inline
----- Original Message ----- 
From: "Jeroen van Bemmel" <[email-masked]>

>1. Configuration of outbound proxies - desire to avoid
>   manual configuration at the UAC. Do we agree that we
>   want this?

Yes, however, if we do #2 below so that a UA can definitively determine that 
the edge proxy supports outbound and the keepalive, and that the home proxy 
supports outbound (i.e. sip.instance and reg-id), this would not necessarily 
be needed immediately.

> 1a If yes, in the outbound draft or as a separate draft?

Again, if we do #2 below, it should be in a separate draft so that it does 
not delay the current outbound draft.

> 2. Detection of outbound/keepalive support - desire for
>    dynamic discovery of support instead of (or perhaps
>    in addition to) static configuration (the current
>    keepalive=stun flag). Do we agree that we want this?
>    (several options have been discussed)

The UA needs to determine definitively that the edge proxy that the UA 
connects to support outbound and the STUN keepalive. It also needs to 
determine whether or not the home-proxy/registrar supports outbound before 
it sends REGISTERs using the reg-id.

> 3b UAC - edge proxy - registrar where the edge proxy adds
>    Path but does not support outbound/keep-alive

I would say no, not with this draft. Those seem like different problems to 
me.

The most pressing requirement is defining a mechanism for a UA to have an 
outbound TCP/TLS connection by which it can receive inbound requests. To me, 
this requires that there be a persistant connection to the first proxy 
(whether it be the edge proxy or the registrar).

You could probably use connection-reuse and the keepalive for 3a.

With 3b, if the edge does not support outbound, it would not send inbound 
requests over the existing connection, so I don't see how that would work at 
all.

With 3c, the UAC would have to establish an outbound connection directly 
with the registrar in order to receive inbound requests.

>In addition, there is ongoing (and seemingly endless) >discussion on STUN 
>for TCP, which can be split into

That was the consensus decision at IETF 65

>5. Do we select / document other (primary) mechanisms?

Based on 4 above, No.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

---

From: iPekka Pessi <[email-masked]>
Date: Thu, 30 Mar 2006 14:54:54 +0300

>1. Configuration of outbound proxies - desire to avoid manual configuration
>at the UAC. Do we agree that we want this?

>2. Detection of outbound/keepalive support - desire for dynamic discovery of
>support instead of (or perhaps in addition to) static configuration (the
>current keepalive=stun flag). Do we agree that we want this? (several
>options have been discussed)

We do. I'd go for outbound feature tag with some more work for
edge proxies and registrar.

1) When an edge proxy receives a REGISTER request with a
sip.instance (and a reg-id?) param in Contact header field, it
would add itself to the Path header. In addition to the flow-id,
it would add keepalive=stun parameter in the Path URI.

2) When registrar receives a REGISTER request with a sip.instance
and reg-id param, it would check for presence of Path headers. If
the last Path header field does not contain keepalive=stun URI
parameter, it MUST NOT include outbound feature tag in 2XX
response and it MUST ignore the reg-id parameter.

So, when registrar includes "outbound" in Supported header, it
knows either
1) edge proxy supports keepalive=stun or
2) it itself supports keepalive=stun.

I hope UAC can trust registrar here. 

As an alternative, we could mandate that the registrar/home proxy
adds its own URI with keepalive=stun to the Path header. Again,
UAC would have to check only one place, the keepalive=stun header
field in last Path header. But that would mean that UAC could not
ignore the Path header as it does now.

In all cases, there is the issue of intermediate proxies not
inserting Path headers. Simplest thing is to count Via headers: if
there is more than one Via header, proxy cannot support
outbound/keepalive=stun unless it has some intimate knowledge of
other proxies listed in the Via headers.

> 3a NAT between the edge proxy and the registrar (or more general: NAT

I would vote for connection reuse in this case. Edge proxy should
have a certificate.

>support outbound/keep-alive

My vote: no outbound, use gruu and hope that Path header is
enough.

> 3c UAC - edge proxy - registrar where the edge proxy does not support/add

You mean that UAC connects directly to registrar? Not in outbound,
I'd say..

--Pekka