Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt

From: [email-masked]
Date: Wed, 22 Mar 2006 18:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Managing Client Initiated Connections in the Session Initiation Protocol (SIP)
	Author(s)	: C. Jennings, R. Mahy
	Filename	: draft-ietf-sip-outbound-03.txt
	Pages		: 31
	Date		: 2006-3-22
	
Session Initiation Protocol (SIP) allows proxy servers to initiate
TCP connections and send asynchronous UDP datagrams to User Agents in
order to deliver requests.  However, many practical considerations,
such as the existence of firewalls and Network Address Translators
(NATs), prevent servers from connecting to User Agents in this way.
Even when a proxy server can open a TCP connection to a User Agent,
most User Agents lack a certificate suitable to act as a TLS
(Transport Layer Security) server.  This specification defines
behaviors for User Agents, registrars and proxy servers that allow
requests to be delivered on existing connections established by the
User Agent.  It also defines keep alive behaviors needed to keep NAT
bindings open and specifies the usage of multiple connections.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-outbound-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-outbound-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Fri, 24 Mar 2006 07:37:33 +0200

outbound version 03 still doesn't address auto-discovery of the
outbound-proxy-set.  as i have said in before, the specification is in
practise useless and should not be published as an RFC unless there is a
standard (preferably DNS based way) to do so.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Mar 2006 09:24:27 -0600

> standard (preferably DNS based way) to do so.

Perhaps we need a SIPPING draft on "basic configuration" or something  
that would represent best current practices?

Or is there a SIP extension needed to support your approach?

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 24 Mar 2006 17:43:26 +0200

> that would represent best current practices?

yes, it may be best practise, if nothing new needs to be standardized.
the requirements for the DNS query result are:

- it tells to UA if outbound proxies implement Outbound I-D and
- if so, it somehow conveys to the UA the proxy tags.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Mar 2006 09:56:08 -0600

> - if so, it somehow conveys to the UA the proxy tags.

Ok, I think we've boiled this down to a new requirement:

for the "outbound" technique to work, we MUST have a means of  
discovering whether a proxy supports the extensions of outbound.

While we could do that by doing a REGISTER exchange that includes an  
appropriate option-tag in Require:, it would be more efficient if the  
proxy discovery mechanism informed us of this detail. So, we posit  
that the Outbound draft SHOULD select and discuss such a mechanism.

Possible alternatives:

1) Deducing from the proxy URL that it supports Outbound. This  
potentially works with DNS, DHCP, and configured discovery, but might  
just be a little too weird with our existing syntax and conventions.

2) Using a different service record in DNS, which works for DNS but  
not DHCP or configured use cases, I think.

We have any other techniques that have been proposed here that I have  
missed?

--
Dean

---

From: Aki Niemi <[email-masked]>
Date: Fri, 24 Mar 2006 18:28:28 +0200

ext Dean Willis wrote:
> 2) Using a different service record in DNS, which works for DNS but not
> DHCP or configured use cases, I think.
> 

3) The proxy corresponding to the entry in the SRV record of a domain,
inspects the Supported of an incoming request for the "outbound" token,
and if it exists, redirects the request either with a new 3xx "connect
to all of these", or use 300 with new bits that indicate this new semantic.

Cheers,
Aki

---

From: Dean Willis <[email-masked]>
Date: Sat, 25 Mar 2006 15:29:25 -0600

Dean Willis wrote:
> proxy discovery mechanism informed us of this detail. So, we posit  that 
> the Outbound draft SHOULD select and discuss such a mechanism.
> 
> Possible alternatives:
> 

Anybody have some furtehr ideas on this?

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 25 Mar 2006 22:53:08 +0100

Dean,

Could you explain why it is needed that the UA knows whether the proxy 
supports outbound before sending its REGISTER request?

With 'lr' this is clear: the UA must formulate the request differently (i.e. 
request URI / Route swap). But when a UA sends a REGISTER with reg-id etc, 
it seems that the worst thing that could happen is that the response does 
not contain 'Supported: outbound' (but otherwise succeeds).

Regards,

jeroen

----- Original Message ----- 
From: "Dean Willis" <[email-masked]>
To: <[email-masked]>
Cc: "Juha Heinanen" <[email-masked]>
Sent: Saturday, March 25, 2006 10:29 PM
Subject: [Sip] How to indicate during proxy discovery that a proxy 
supports"outbound"

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 26 Mar 2006 08:27:11 +0300

> not contain 'Supported: outbound' (but otherwise succeeds).

if wg meeting decided that there is only one choice for keepalive
protocol (stun), then ";keepalive=xxx" tag is not needed anymore and
";lr" could be default.

if so, the default behavior could be that SIP UA makes SRV query and
sends REGISTER request to the resulting proxies.  if, as you say,
REGISTER reply contains "Supported: outbound", then SIP UA knows that
the proxies implement outbound I-D and it starts to behave as specified
in outbound-id.

-- juha

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sun, 26 Mar 2006 00:54:12 -0500

Actually I don't think the UA knows the proxies support it - only that the
Registrar does (since the proxies don't insert in supported, nor delete from
it if they don't).

There is a way around that - insert a require-proxy and if it's rejected
with a 420 then you know.

I'm with you that more UA configuration is bad.

The second problem is they left the TCP keepalive mechanism in, leaving the
door open for a UA which can't do stun in the same port, to talk to a
sip-outbound server using the rest of the sip-outbound mechanisms. (I think)

-hadriel

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Sunday, March 26, 2006 12:27 AM
> To: Jeroen van Bemmel
> Cc: [email-masked]; Dean Willis
> Subject: Re: [Sip] How to indicate during proxy discovery that a
> proxysupports"outbound"
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 26 Mar 2006 13:13:36 +0200

> with a 420 then you know.

Right, I thought about that too. Perhaps the edge proxy should add a flag to 
its Path header indicating that it supports outbound. The Proxy-Require 
approach you mention above would introduce another round trip, which is best 
avoided

So in summary, the mechanism I would propose at the UAC for detection of 
outbound support:
don't add 'keepalive=xxx' to the configured outbound proxy URI, instead 
first check for Path headers containing a TBD flag (say "outbound"). If 
there are no Path headers, check for Supported: outbound

If there is a need to indicate support for a specific keepalive mechanism 
(i.e. there are multiple choices), the Path approach can easily be extended. 
'Supported' allows no parameters, so one could either define a specific 
option tag for each keepalive mechanism, or do it in some other way

Regards,

jeroen

---

From: Dean Willis <[email-masked]>
Date: Sun, 26 Mar 2006 16:14:45 -0600

Jeroen van Bemmel wrote:
> With 'lr' this is clear: the UA must formulate the request differently 
> (i.e. request URI / Route swap). But when a UA sends a REGISTER with 
> reg-id etc, it seems that the worst thing that could happen is that the 
> response does not contain 'Supported: outbound' (but otherwise succeeds).

Good question. Critical question for establishing a requirement, so 
let's see if we can answer it.

There are two ways we can establish compatibility with an extensions:

1) By foreknowledge
2) By experimentation -- try it and see if it works.

Both have limitations:

In the case of #1, we might have incorrect knowledge. So we'll probably 
end up testing anyhow . . .

In the case of #2, the experiment might cause a meltdown. So the "probe 
for discovery" must be made completely safe.  Also, we can eventually 
end up with so many wierd hooks and idiosyncratic implementations that 
we end up doing a BUNCH of probing before we do any real communicating. 
And it's possible for the conditions to deteriorate so much that probes 
for two different possible conditions are mutually exclusive -- if one 
condition applies, the probe for another will cause a meltdown.

So what happens if we start STUN-probing a proxy on its SIP port and it 
doesn't support STUN? My guess is, it's random.

So, we should "probe for discover" only when we either expect it tow 
work (via foreknowledge) or we know that the test is completely safe.

The -03 text says:

4.4.1  Keep Alive with STUN

    User Agents that form flows MUST check if the configured URI they are
    connecting to has a 'keepalive' URI parameter (defined in Section 10)
    with the value of 'stun'.  If the parameter is present, the UA needs
    to periodically perform keep alive checks by sending a STUN [7]
    Binding Requests over the flow.

So there's a presumption that it is IMPORTANT that we know that a proxy 
supports keepalive using STUN. Note that we don't blindly probe, because 
  the probe might well be destructive to an unsupporting proxy.

I had a very interesting talk last week with Yngve Petterson, one of the 
developers of the "Opera" browswer. He does a lot of work with SSL/TLS, 
and cautioned me that we need to think very carefully about "forward 
compatibility" design in SIP. TLS didn't, so they end up having this 
complex negotiation process where they try things and hope it works. 
Sometimes it takes several from-scratch connection start attempts before 
a "magic combination that works" is discovered.

One approach to "forward compatibility" design is to make sure that we 
can use both foreknowledge and experimentation -- the "trust but verify" 
model.

We also have "foreknowledge" -03:

4.2  Initial Registrations

    UAs are configured with one or more SIP URIs representing the default
    outbound-proxy-set.  The specification assumes the set is determined
    via configuration but future specifications may define other
    mechanisms such as using DNS to discover this set.

While it's easy to decide whether a configured registrar URI has a 
keepalive parameter, what happens to proxies we select based on 
something besides direct configuration?

Specifically,

1) Can the DHCP option for default proxy present the keepalive 
parameter? I haven't looked yet . . .

2) Can a UA using the mechanismn suggested by Juha, which I read as 
"look in DNS for an SRV record supporting the domain of the AOR" present 
the keepalive parameter?

If not, how do we get around the limitation?

--
dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sun, 26 Mar 2006 21:56:47 -0500

> From: Dean Willis [mailto:[email-masked]]
> Sent: Sunday, March 26, 2006 5:15 PM
> To: Jeroen van Bemmel
> Cc: [email-masked]; Juha Heinanen

There is a 3rd: explicit, signaled negotiation.

I don't think anyone is asking for a stun probe to check if the server
supports it. (at least I haven't interpreted that)  I agree that would be a
bad way to go.  But why would that be needed - isn't stun sent *after*
registration?

There are mechanisms to check sip-outbound compliance in this, right?  And
since you mandate the server support stun, then if it indicates to the UA
outbound compliance, you're done.  The only rub is the current draft doesn't
take into account a proxy indicating outbound compliance.  So you can either
mandate explicitly verifying through proxy-require (and require: while
you're at it), which would take one extra round-trip only if it fails.  Or
make the UA add something in the Register that a sip-outbound compliant
proxy would remove, or whatever.  Then mandate stun can't be sent until
registration is complete and the next-hop indicated support for outbound.

If you're worried about a "proxy" being in the path that isn't "visible",
then it may not be "visible" to the person doing configuration either.  Or
configuration screw-ups may be problems too.  As so often argued against
SBCs in this forum: I'm not sure we should be worried about non-compliant
phantom boxes.  We just have to make sure it won't break compliant ones.

The only real solution otherwise would be to make this a new default port
and SRV record service type for "SIP-O" and "SIPS-O", or some such, since
what you are implying is the outbound mechanism is fundamentally different
than SIP, I think.  But my view is that would be worse than just negotiating
it using SIP.

> 4.4.1  Keep Alive with STUN
[snipped]

I should note that as far as I can tell, the draft says a UA with the
keepalive=stun URI MUST use stun, but does not mandate that for a URI
without it the UA MUST NOT use stun. (no?)

So I think we are allowing a UA to send STUN without foreknowledge the
next-hop can handle it.

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sun, 26 Mar 2006 22:13:50 -0500

> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Sunday, March 26, 2006 6:14 AM
> To: Hadriel Kaplan; 'Juha Heinanen'
> Cc: [email-masked]; 'Dean Willis'

But there are 3261 compliant proxies out there that don't support Path.  So
you will not know if the register went through one of those and hit an
outbound registrar, vs. there was no proxy.  I think a proxy-require is the
only safe bet (and it would work across multiple proxies).  It only means an
extra round-trip if it fails, and the truth is you do require the proxy to
support something, so why not use the header defined for that?

> option tag for each keepalive mechanism, or do it in some other way

I think once the UA figures out the next-hop can do outbound, it knows it
can do stun, because servers are mandated to support stun if they support
outbound. 

-hadriel

---

From: Fredrik Thulin <[email-masked]>
Date: Mon, 27 Mar 2006 09:26:04 +0200

On Monday 27 March 2006 05:13, Hadriel Kaplan wrote:
...
> > So in summary, the mechanism I would propose at the UAC for
> > detection of outbound support:
> > don't add 'keepalive=xxx' to the configured outbound proxy URI,
> > instead first check for Path headers containing a TBD flag (say
> > "outbound"). If there are no Path headers, check for Supported:
> > outbound
>
> But there are 3261 compliant proxies out there that don't support
> Path.  So you will not know if the register went through one of those
> and hit an outbound registrar, vs. there was no proxy.  I think a
> proxy-require is the only safe bet (and it would work across multiple
> proxies).  It only means an extra round-trip if it fails, and the
> truth is you do require the proxy to support something, so why not
> use the header defined for that?
>
> > 'Supported' allows no parameters, so one could either define a
> > specific option tag for each keepalive mechanism, or do it in some
> > other way
>
> I think once the UA figures out the next-hop can do outbound, it
> knows it can do stun, because servers are mandated to support stun if
> they support outbound.

Proxy-Require: outbound won't work when the next-hop from the UA 
supports outbound, but other proxies on the way to the home proxy 
(registrar) does not.

Consider the following :

  UA --- | --- P1 --- P2 --- Registrar
        NAT

P1 supports Outbound, and is there to help the UA traverse the NAT.
P2 is the proxy indicated in DNS for the UA's "home domain", but it 
proxies all REGISTER requests to Registrar. P2 does not support 
Outbound, and should not be required to do so.

/Fredrik

---

From: <[email-masked]>
Date: Mon, 27 Mar 2006 15:09:55 +0300

Hi,

Here is my short summary about the proposals given, problems

>discovering whether a proxy supports the extensions of outbound.

I fully agree with this requirement, since there are use cases
(e.g. with DHCP SIP proxy discovery) where outbound support can
simply not be found from the UA configuration.

A. Negotiation with SIP

>Supported: I don't think the UA knows the proxies support it - 
>only that the Registrar does (since the proxies don't insert 
>in supported, nor delete from it if they don't).

>Path: But there are 3261 compliant proxies out there that don't 
>support Path.  So you will not know if the register went through 
>one of those and hit an outbound registrar, vs. there was no proxy. 

B. Using DNS

>The only real solution otherwise would be to make this a new default 
>port and SRV record service type for "SIP-O" and "SIPS-O", or some 
>such, since what you are implying is the outbound mechanism is 
>fundamentally different than SIP, I think.

I do not think a new default port is needed since you can always
indicate the port within SRV records.

But apart that I believe this would be the way to go i.e. to
define a few new NAPTR service types for Outbound, something like:

"SIPS-O+D2T" "SIP-O+D2T" "SIP-O+D2U"

Benefits of this solution:

- Would enable the UA to specifically select the proxies 
  supporting Outbound, instead of only blindly trying whether 
  any of the resolved proxies would support it

- Would tell the UA whether the proxy supports Outbound or not
  even before starting to communicate the proxy and avoids the
  extra transactions caused by the proxy rejecting or redirecting
  the REGISTER request

- Would also support the case where domain name of the proxy
  is discovered by DHCP. As DHCP returns proxy domain names
  without port or transport, it causes the UA to make a NAPTR
  query for that domain, according to RFC 3263

- Does not introduce backwards compatibility problems for UAs
  not supporting Outbound, since those UAs would discard those
  new NAPTR service types according to RFC 3263 rules

- No new SRV records would be needed since those new NAPTR records
  could be mapped to the very same SRV RRs that would be used for 
  good old "SIPS+D2T" "SIP+D2T" "SIP+D2U" services, if the same
  proxy could be used with or without Outbound

Drawbacks of the solution:

- Three new NAPTR service types and records needed for introducing
  one new type of service

- Relies on the UA to implement NAPTR processing (which I think
  is reasonable as Outbound has a number of new reqs anyway)

Further on I would like to propose handling of the primary and
backup proxy issue ...

>While outbound promotes ways for using multiple connections towards
>multiple proxies it does not yet address the problem of discovering
>those proxies 

... so that if the service resolved is "SIP-O+D2X" then the UA
could open a separate connection towards the preferred proxy
at each priority level of the SRV records for the service.
This would be a change to RFC 3263 procedures, that result
connecting to only one single proxy and then exiting the search.

Comments, please ?

Erkki

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 27 Mar 2006 11:50:24 -0500

Actually, my impression is that P2 may have to support understanding
outbound.  The proxy forwarding rules changed in outbound.  If P2 doesn't
support outbound, and is the one doing location lookups, it may fork
requests to the same UA through P1a and P1b to reach the UA. (not that
that's a huge deal I guess, but it sounds bad to me that P2 could always be
forking requests)

It's also a problem because outbound needs the edge proxies to support Path,
and if P2 doesn't and it's the one doing location lookups it may not send
the request through P1. (depending on how it does location lookups)

Outbound also fundamentally changes the redundancy mechanism for failure
support from what I think is the current norm, and this change affects the
load and signaling distribution on registrars and proxies.  So my guess is
operators would prefer UAs only do outbound if the operator fully supports
it. 

So to be safe I would think all the P's between the UA and the registrar
have to "support" outbound. (note that doesn't mean they have to all handle
stun nor add a Path)

-hadriel
p.s. although it's not in scope for this draft, for IMS you would lose the
ability to use an I-CSCF which does not understand sip-outbound with
P/S-CSCFs that do, but I don't think that's a real issue, is it?  If the
I-CSCF does not want to be in the session path, 3GPP can specify that it
accepts the proxy-require: outbound but not add a path (which is compliant
with this draft).  The I-CSCF would not have to implement stun because per
this draft only servers talking directly with UAs have to.  But no matter
what my guess is you'll want the i-cscf to "understand" outbound anyway for
register routing purposes, and since the p-cscf and s-cscf have to change
for outbound, updating the i-cscf is hardly more work.

> From: Fredrik Thulin [mailto:[email-masked]]
> Sent: Monday, March 27, 2006 2:26 AM
> To: [email-masked]
> Cc: Hadriel Kaplan; 'Jeroen van Bemmel'; 'Juha Heinanen'; 'Dean Willis'

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 27 Mar 2006 12:29:47 -0500

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 27, 2006 7:10 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sip] How to indicate during proxy discovery
> thataproxysupports"outbound"
> 

Yes, I would definitely prefer a mechanism which allows the UA to discover
the primary/backup dynamically rather than through more configuration, and
it allows the operator to control support of the new redundancy model.  The
only other way to do the latter I could think of would be with 2 option-tags
for supported (e.g., one for "outbound", one for "outbound-redundant").  But
your way is cleaner, and lets the operator control how many redundant
connections would be used.

-hadriel

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 27 Mar 2006 23:37:53 +0200

There are several arguments against the DNS SRV approach:
- it still introduces a potential for misconfiguration (discrepancy between 
what is configured in DNS versus what's actually deployed and enabled)
- it doesn't help proxies on the path to detect upstream support for STUN 
keepalive (unless each proxy would perform dynamic discovery too?)

Perhaps it could be used in conjunction with the following (inspired by 
'rport'):

UAC :
- REGISTER request: adds a 'keepalive' flag to the Via header
- REGISTER response: checks top via for supported keepalive protocols
Edge proxy / registrar:
- REGISTER request: checks top Via in REGISTER for keepalive, if present 
adds 'keepalive' to its Via header when forwarding
- REGISTER response: if request had keepalive, adds list of supported 
keepalive protocols to it

At the registrar, if the top Via contains 'keepalive' it means that all 
proxies on the path support it. Perhaps this should be conveyed to the UAC 
in some way. Other than that, upon return the 'keepalive' lists the 
supported keepalive mechanisms. It would be specific for the protocol used 
in the Via header. Both the UAC and edge proxies should use one of the 
supported keepalive mechanisms, preferrably TCP keepalive (which need not be 
explicitly in the list, as it does not require specific server 
functionality). Each path segment would use indepedent keepalives, which is 
good for performance reasons (several UACs could share the edge proxy, and 
it would only use 1 flow (with keepalive) towards the registrar).

This would support an arbitrary number of proxies between the UAC and the 
registrar, even when some of them do not support outbound

Example:

REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/TCP 10.0.1.1;branch=z9hG4bKnashds7;keepalive
   Max-Forwards: 70
   From: Callee <sip:[email-masked]>;tag=a73kszlfl
   To: Callee <sip:[email-masked]>
   Call-ID: [email-masked]
   CSeq: 1 REGISTER
   Supported: path
   Route: <sip:primary.example.com;lr;keepalive=stun>
   Contact: <sip:[email-masked]>
     ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     ;reg-id=1
   Content-Length: 0SIP/2.0 200 OK
   Via: SIP/2.0/TCP 10.0.1.1;branch=z9hG4bKnashds7;keepalive="stun"
   From: Callee <sip:[email-masked]>;tag=a73kszlfl
   To: Callee <sip:[email-masked]> ;tag=b88sn
   Call-ID: [email-masked]
   CSeq: 1 REGISTER
   Supported: outbound
   Contact: <sip:[email-masked]>
     ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     ;reg-id=1
     ;expires=3600
   Content-Length: 0-------------------
Secondly, consider a deployment with an edge proxy that does not support 
outbound, and a UAC / registrar that do (with NAT between the edge proxy and 
the UAC). I think this may represent a case that calls for an end-to-end 
keepalive mechanism (i.e. PING / OPTIONS / whatever) which is initiated by 
the UAC, and proxied by the edge proxy. This would refresh the NAT binding. 
Do we want to support this scenario too?

Regards,

Jeroen

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 27 Mar 2006 18:06:04 -0500

Hi Jeroen, (or perhaps, Goedenavond?)
Comments inline...

> Sent: Monday, March 27, 2006 4:38 PM
> To: Hadriel Kaplan; [email-masked]; [email-masked]
> Subject: Re: [Sip] How to indicate during proxy
> discoverythataproxysupports"outbound"
> 

Not a bad one though.  If the UA gets an SRV for SIP, it does regular SIP.
If it gets SIP-O, it does sip-outbound.  If a non sip-outbound UA gets
SIP-O, it ignores it.

So the worst case is you get UAs that could be doing outbound but end up
doing regular SIP.  If you have no NATted users, no problem.  If you relied
on outbound as your only NAT traversal mechanism, you'll find out soon
enough that you mis-configured DNS, and you have the staff to fix it, and
they're trained.  The problem is fixed in one step for everyone, and it was
a problem you created.

If users mis-configure their UAs and set the keepalive=stun flag, even if
they are NOT behind NATs, you get STUN messages on proxies with undetermined
results, appearing from numerous ports/addresses; then try to get a hold of
all the users to fix it, using much more staff talking to untrained
consumers.  And the problem continues as you add more users.  All along you
supported RFC 3261 and the other relevant IETF specs, and the sip working
group created a new, continuous problem for you until you update the proxies
to the draft, or buy SBCs.  Oh, wait... I like this problem.  :)

> keepalive (unless each proxy would perform dynamic discovery too?)

Downstream proxies don't need to know if upstream ones support stun.  Only
the first server the UA touches needs to support stun, no?  That's per the
draft too, I think.

There is a latent issue that you may want to verify (all) the proxies
support outbound, but no one else has agreed that may be needed. (multiple
proxies are out of scope I think?)
I was only saying if you knew the closest/first proxy did outbound, then
you'd know it did stun.  Knowing about the other proxies supporting outbound
was a bonus.

-hadriel

---

From: Fredrik Thulin <[email-masked]>
Date: Tue, 28 Mar 2006 08:08:12 +0200

On Monday 27 March 2006 18:50, Hadriel Kaplan wrote:
> outbound.  The proxy forwarding rules changed in outbound. 

My impression is that the edge proxys, and the ones doing location 
service lookups, have to support Outbound - not any intermediate 
proxys. This is a good thing IMO.

> If P2 
> doesn't support outbound, and is the one doing location lookups, it
> may fork requests to the same UA through P1a and P1b to reach the UA.

Yes, in another scenario than the one I put forward this would perhaps 
be true, but I haven't said that P2 would need to support Outbound _if 
it was a proxy that did location service lookups_.

...
> So to be safe I would think all the P's between the UA and the
> registrar have to "support" outbound. (note that doesn't mean they
> have to all handle stun nor add a Path)

I don't give much for the 'let's just say every proxy needs to support 
every extension'. If Outbound can be made to work with 'just' the edge 
proxys and the proxys doing location service read/writes supporting 
Outbound, then I think that is the right thing. 

I'd say that this is the case currently - all the routing logic in the 
current Outbound draft would work without P2 supporting Outbound. The 
question now is how the UA could discover that P1 supports STUN 
keepalives, or something else.

/Fredrik

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 28 Mar 2006 08:13:58 +0200

> support something, so why not use the header defined for that?

If the outbound proxy does not support Path, it also does not support 
outbound. In either case the UAC could detect this (i.e. no Path header 
matching outbound proxy -> proxy does not support outbound). The problem 
could be with proxies that ~do~ support Path, but for one reason or another 
do not wish to be in the path for inbound requests. On the other hand: 
keepalive is only required for the path that inbound requests follow!

So even in a (complex) setup like the following:
UAC - P1 - P2 - registrar
where P1 does not add a Path header, the UAC would be required to keep alive 
the connection towards P2 (indeed, set one up in case of TCP)

RFC3327 currently says that the UAC can ignore Path headers in the REGISTER 
response. If scenario's as the one sketched above are to be supported, it 
seems like it will have to inspect them, find the last value, and use 
keepalive towards that hop. This also has security implications.

This is getting complicated. In my opinion, the outbound draft at least has 
to be very specific about the types of deployments that it supports, and the 
assumptions made about intermediate proxies.
It currently covers 2 cases:
1. Single Registrar and UA (section 3.2)
2. Edge Proxies with UAC directly behind NAT (section 3.4)

There are at least 2 cases missing:
3. (2) with NAT after the edge proxies (edge proxies would need to do 
keepalive for this)
4. a chain of edge proxies (as in RFC3327 section 5.5.1), in particular when 
some of these don't add Path (and/or don't support outbound); UAC would need 
to do keepalive towards last Path entry

Regards,

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 28 Mar 2006 09:29:35 +0300

> "SIPS-O+D2T" "SIP-O+D2T" "SIP-O+D2U"

erkki,

many UAs on the market don't currently do NAPTR lookups, but only SRV
lookups.  so perhaps it would be easier for both implementation and
standardization reasons to introduce _sip_out._proto.domain SRV records
in addition to current _sip._proto.domain SRV records.

by the way, no matter what kind of DNS solution is selected, one
addition advantage of DNS is that separate proxies could be installed
for use by local SIP UAs and foreign SIP UAs and peers.  that is, local
SIP UAs would make _sip_out._proto.domain SRV queries and foreign ones
would keep on querying _sip._proto.domain SRV records.

-- juha

---

From: <[email-masked]>
Date: Tue, 28 Mar 2006 10:10:16 +0300

Hi Juha,

I have also thought about the option you outlined but I
found some complication with it at least for those UAs
that do support NAPTR processing according to RFC 3263.

Should NAPTR only have those good old services "SIPS+D2T",
"SIP+D2T" and "SIP+D2U" or should the new "-O" services
be introduced additionally to the new types of SRV records ?

I would like to start with the first case (trying to avoid
introducing new concepts to both NAPTR and SRV):

So let's assume that DNS has been configured with both
_sip._proto.domain and _sip_out._proto.domain SRV records.
What should the NAPTR query for domain in that case return 
for e.g. "SIP+D2U" ?

- If it returns both _sip._proto.domain and _sip_out._proto.domain
  then the same proxy servers might appear within the SRV records
  twice. Not good. Further on the UAs wanting Outbound service
  would need to discard _sip._proto.domain SRV records before
  sorting them as described in RFC 2782. Not nice either.

- If it only returns _sip_out._proto.domain records then the
  UAs expecting Outbound support would be happy. However if 
  there is any reason for an UA to try finding or using a proxy
  without Outbound, then it turns out to be impossible with 
  NAPTR. This sounds too restrictive to me and would not allow
  the use case outlined by Fredrik:

> A real life example : I want people trying to reach my users
> to look up NAPTR/SRV for 'it.su.se' (naturally) but I want my 
> clients to use other servers, currently indicated by NAPTR/SRV 
> records for 'out.sip.su.se' because these other servers do 
> stuff like Outbound, which the 'it.su.se' servers does not.

So I would think, additionally to introducing the new type of
SRV records, the new NAPTR service types would anyway be necessary.
Then the question is, are those new types of SRV records _really_
needed as they would add one extra piece of new specification,
complexity and source of errors for DNS configuration ?

>many UAs on the market don't currently do NAPTR lookups, 
>but only SRV lookups.

But those UAs do not support Outbound either (as we are just
now specifying it). So the real issue boils down to this:

Will implementing NAPTR support for those UAs be really so
much more difficult than implementing other new aspects
of Outbound (URN instance ID creation, STUN keepalives,
flow recovery, changes of DNS SRV record usage for using 
backup proxies) so that there is no way for the Outbound 
to rely on NAPTR ?

After running a project that implemented NAPTR to an UA
I do not find this too hard, unless the OS on top of which
the UA SW is running does simply not support DNS NAPTR RRs.
In my opinion the solution you suggest is possible but not
very elegant as NAPTR RRs can not be ignored.

Regards,

Erkki

>From: ext Juha Heinanen [mailto:[email-masked]] 
>Sent: 28.March.2006 09:30
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: RE: [Sip] How to indicate during proxy discovery that 
>aproxysupports"outbound"
>

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 28 Mar 2006 08:49:51 -0500

inline
----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>

>
> Actually, my impression is that P2 may have to support
> understanding outbound.  The proxy forwarding rules changed
> in outbound.

Intermediate proxies do not have to support outbound. The forwarding rules 
have changed for the registrar/home-proxy and the edge proxy, not for other 
intermediate proxies. P2 would see a Route header pointing at P1.

>  If P2 doesn't support outbound, and is the one
> doing location lookups, it may fork requests to the same UA
> through P1a and P1b to reach the UA. (not that that's a huge
> deal I guess, but it sounds bad to me that P2 could always
> be forking requests)

If P2 is doing location lookups in the registrar (i.e. inbound requests go 
to P2 rather than the registrar), then it qualifies as the home proxy and 
would need to support outbound so that it would not fork the request.

>
> It's also a problem because outbound needs the edge proxies
> to support Path, and if P2 doesn't and it's the one doing
> location lookups it may not send the request through P1.
> (depending on how it does location lookups)
>
> Outbound also fundamentally changes the redundancy mechanism
> for failure support from what I think is the current norm,
> and this change affects the load and signaling distribution
> on registrars and proxies.  So my guess is operators would
> prefer UAs only do outbound if the operator fully supports it.
>
> So to be safe I would think all the P's between the UA and
> the registrar have to "support" outbound. (note that doesn't
> mean they have to all handle stun nor add a Path)

Again, only the "home proxy" (the one that does location lookup in the 
registration data base), and the edge proxy (the one the UA has a direct 
connection to) need to support the outbound draft and Path. Intermediate 
proxies would see a Route header inserted by the home proxy on request 
inbound to the UA. Besides, if the intervening proxy did not add a Path 
header to the REGISTER, it probably would not even receive the inbound 
request.

>
> -hadriel
> p.s. although it's not in scope for this draft, for IMS you
> would lose the ability to use an I-CSCF which does not
> understand sip-outbound with P/S-CSCFs that do, but I don't
> think that's a real issue, is it?  If the I-CSCF does not
> want to be in the session path, 3GPP can specify that it
> accepts the proxy-require: outbound but not add a path
> (which is compliant with this draft).  The I-CSCF would
> not have to implement stun because per this draft only
> servers talking directly with UAs have to.  But no matter
> what my guess is you'll want the i-cscf to "understand"
> outbound anyway for register routing purposes, and since
> the p-cscf and s-cscf have to change for outbound, updating
> the i-cscf is hardly more work.
>
>

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 28 Mar 2006 17:01:06 +0300

erkki,

i guess we would need to introduce new "O" NAPTR service types to be
used only by SIP UAs that require outbound service.  old SIP UAs as well
as proxies would keep on querying the old service types.

 > What should the NAPTR query for domain in that case return 

it would return only _sip._proto.domain SRV records.

 >   sorting them as described in RFC 2782. Not nice either.

i agree, not good.

 > > stuff like Outbound, which the 'it.su.se' servers does not.

yes, and this is solved by introducing new "O" NAPTR service types,
which would only be queried by SIP UAs requiring outbound services.

 > SRV records, the new NAPTR service types would anyway be necessary.

yes, for those SIP UAs that do implement NAPTR lookups.

 > complexity and source of errors for DNS configuration ?

yes, IF we want to support SIP UAs that don't implement NAPTR lookups at
all and do directly SRV lookups.  so if such an UA requires outbound
service, it would query _sip_out._proto.domain and if not it would query
_sip._proto.domain SRV records.

 > backup proxies) so that there is no way for the Outbound 

that is what the WG needs to decide: do we make NAPTR lookup a MUST for
SIP UAs implementing outbound I-D?  a MUST would make SIP UA
implementation more complex, but it would also make DNS provisioning
more complex, because now EVERY domain would need to have both NAPTR and
SRV records configured for it.

-- juha

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 28 Mar 2006 13:45:26 -0500

> "SIP+D2T" and "SIP+D2U" or should the new "-O" services be 
> introduced additionally to the new types of SRV records ?

I have no strong preference.  However this requires configuration of extra
records and requires the records to stay aligned concerning ports.  If the
NAPTR records are good enough (and needed for indicating outbound support),
defining a new flag to indicate stun supported on this sip transport target
helps keep things aligned.

And concerning the potential use of option tags within Require, Supported,
etcetera, I do not think they are adequate since they do not indicate which
device added it.

Via header manipulation would likely work; however it introduces a little
extra processing overhead on the target.  UAC adds Via parameter "outbound".
And when the proxy/UAS observes it and supports receiving stun on this
port/connection, it adds a parameter like "outbound=supported" or
"outbound=required".

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 29 Mar 2006 08:23:36 +0200

> SRV records configured for it.

To me this is all becoming way too heavy, and seems likely to introduce more 
problems than it solves

The DNS discussion I have seen so far seems to assume that the outbound 
proxy is in the same domain as the home registrar. This is not always the 
case, in fact I expect that often it will ~not~ be the case. Therefore, 
local discovery mechanisms like DHCP and broadcast (as described in RFC3261) 
seem more appropriate to me. I understand the desire / requirement for 
automatic provisioning for specific (large scale) deployments, but this 
should not be mandated for everybody, IMHO

I vote for a separate draft on this topic

Regards,

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 29 Mar 2006 10:20:28 +0300

Jeroen van Bemmel writes:

 > I understand the desire / requirement for 

i don't think anyone has proposed mandating to USE DNS discovery.  it is
just intended as the default Internet mode of operation that can be used
when SIP UA can directly reach its home proxy/registrar.  if your
situation involves firewalls, SBCs or some other components whose
operation is not defined by IETF, you can override the default mode of
operation and use DHCP, manual configuration, TFTP or whatever.

-- juha

---

From: <[email-masked]>
Date: Wed, 29 Mar 2006 10:45:50 +0300

Hi Jeroen,

>The DNS discussion I have seen so far seems to assume 
>that the outbound proxy is in the same domain as the 
>home registrar. This is not always the case.
>Therefore, local discovery mechanisms like DHCP and 
>broadcast (as described in RFC3261) seem more 
>appropriate to me.

I believe you miss at least some of the point. The DNS
procedure covers also the DHCP case. DHCP typically
provides you the domain name of the SIP proxy like
proxy.example.com. So what shall the UA do with that
domain name, resolve it with DNS A query ? 

Following RFC 3263 that is not the right answer since
the domain name comes without port and transport information.
The UA should do at first a NAPTR query for that domain and
if it does not find any NAPTR records, then SRV queries for
service and protocol it likes to use. A query is only the
last resort if neither NAPTR or SRV records are available.

So the DNS NAPTR and SRV procedures specifically cover
also the DHCP case like I mentioned already earlier:

>I vote for a separate draft on this topic

Anyway since the proposed DNS procedures would impact the
contents of RFC 3263 (new service types) a separate draft
could be a reasonable approach.

Regards,

Erkki

>From: ext Jeroen van Bemmel [mailto:[email-masked]] 
>Sent: 29.March.2006 09:24
>To: Juha Heinanen; Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [Sip] How to indicate during proxy discovery

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 29 Mar 2006 11:04:26 +0300

Fredrik Thulin writes:

 > In my opinion, Outbound does not need to take non-RFC3261/3263 compliant 
 > UAs in consideration.

fine with me, juha

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 29 Mar 2006 03:19:40 -0500

Hi Jeroen,
Comments inline...

> Sent: Tuesday, March 28, 2006 1:14 AM
>
> > only safe bet (and it would work across multiple proxies).  It only
> means
> > an

Actually, I'm pretty sure keepalive is required for the first sip box the UA
hits (the one outbound and inbound requests follow), because your
nat-hole-flow is to it.  I don't see how it's possible for your Register to
go to a first proxy which is not in both the inbound and outbound request
flow.  How would the request get back through the nat-hole or TCP socket?

More importantly, the local proxy could very well do Path but NOT support
outbound.  So you'll be doing it when you shouldn't.

Second, it may be just a registrar without a proxy (no path header).  So you
won't be doing outbound when you should.  (at least, I don't think a
registrar supporting Path actually inserts it if it's an empty set, and it
itself is not in the uri set)

Fourth, if it's a proxy that does Path, there is no assurance the URI you
get in the returned 200ok Path is its URI to you.  Proxies can have multiple
interfaces, and the Path URI will be the one pointing to the registrar, no?
So you won't be doing outbound when you should.

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 29 Mar 2006 03:34:05 -0500

> Sent: Tuesday, March 28, 2006 1:08 AM
> To: Hadriel Kaplan
> 

Cool with me - that was all I was asking for.  Checking the intermediates
seemed like gravy to me, but one man's gravy is another man's dirty soup.  
Find a way that works every time and I'll shut up... about this topic. :)

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 29 Mar 2006 03:37:00 -0500

Hey Bob, 
Inline...

> From: Bob Penfield [mailto:[email-masked]]
> Sent: Tuesday, March 28, 2006 8:50 AM
> To: Hadriel Kaplan; 'Fredrik Thulin'; [email-masked]
> Subject: Re: [Sip] How to indicate during proxy discovery that
> aproxysupports"outbound"
> 

Yup - I was only referring to the case of P2 being the one doing location
lookups.  (his drawing only had P1 and P2 and a registrar, so that was a
possibility in my paranoid interpretation)

> would need to support outbound so that it would not fork the request.

Exactly.  But this draft-03, as written, does not stop the UA from
performing outbound (and stun) even when the configuration flag is NOT set,
and even when P2 does NOT indicate support for outbound.  It's totally up to
the UA.  

>From a protocol interop point of view, it's bizarre to me that the sender
would be more liberal and the receiver would be less. (not from a security
use of those words though)

Is that an error in my interpretation/reading, or an error in the draft?
I've read it a few times now and I can't seem to find anything stopping a UA
from simply performing outbound (and sending STUN) at its own discretion,
regardless of flags or supported: outbound responses.

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 29 Mar 2006 03:53:46 -0500

> header to the REGISTER, it probably would not even receive the inbound

Of course - but I can think of no other way, other than proxy-require and
require, to be as sure as possible that the first edge sip box supports the
new draft (and ergo STUN).  Even a DNS-based SRV mechanism is flawed, simply
because so many don't use SRV (and there's DHCP, et al).  There has to also
be an active check.

One could have the sip-outbound compliant box actually _remove_ the
proxy-require: outbound option-tag, which would only happen if it supported
sip-outbound, and it could then forward the request on.  And the
sip-outbound compliant registrar is covered by the Require: option-tag idea.
That way if the first box (proxy or registrar) wasn't sip-outbound, it would
reject it.  If the first box was sip-outbound compliant, the Register would
get through a chain of any proxies and succeed (by not responding with a
420).  At least that sounds right without thinking about it for too long, at
4am. :)

But that would mean the first edge proxy would need to change from being a
pure sip proxy... which now that I think about it, is exactly what the draft
is already doing.  

-hadriel

---

From: Fredrik Thulin <[email-masked]>
Date: Wed, 29 Mar 2006 09:40:21 +0200

On Tuesday 28 March 2006 16:01, Juha Heinanen wrote:
...
> that is what the WG needs to decide: do we make NAPTR lookup a MUST
> for SIP UAs implementing outbound I-D?  a MUST would make SIP UA
> more complex, because now EVERY domain would need to have both NAPTR
> and SRV records configured for it.

I don't get this. UAs should have implemented NAPTR resolving years ago, 
when they started being RFC3261/3263 compliant, right?

It's the SRV records in every domain that should go away - they are the 
ones making the DNS provisioning complex.

/Fredrik

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 29 Mar 2006 04:42:51 -0500

Hi Brett,

> From: Brett Tate [mailto:[email-masked]]
> Sent: Tuesday, March 28, 2006 1:45 PM
> 

Oh, an excellent idea.  It's slightly less secure than a proxy-require, but
it's a test without a failure round-trip.  And it's hardly much overhead
compared to being the edge proxy or UA for outbound anyway.  And it's
potentially a re-usable concept for a future draft for a proxy-to-proxy
keepalive check.

The only down-side is etiquette requires you to send the text for the draft
if other people agree.  ;)

-hadriel

---

From: Klaus Darilion <[email-masked]>
Date: Wed, 29 Mar 2006 15:56:32 +0200

>> DHCP or configured use cases, I think.

If there is a local outbound proxy required and configured by DHCP, the 
client can use this proxy. Further, this proxy could use DNS based 
methods to find out if the service provider also provides an edge proxy.

regards
klaus

---

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

Hadriel,

see inline

Jeroen

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "'Jeroen van Bemmel'" <[email-masked]>
Cc: <[email-masked]>; "'Dean Willis'" <[email-masked]>
Sent: Wednesday, March 29, 2006 10:19 AM
Subject: RE: [Sip] How to indicate during proxy discovery that a 
proxysupports"outbound"

> flow.  How would the request get back through the nat-hole or TCP socket?

That was exactly my point: what happens if the first proxy does not add 
Path? Assuming there is NAT (or something else preventing direct 
reachability), the UAC would have to establish a flow with the next hop on 
the path, i.e. the host corresponding to the last entry in the Path header 
value (possible issue as you mention below). If there is no Path header, it 
will have to connect directly to the registrar.

> outbound.  So you'll be doing it when you shouldn't.

The idea was to add a flag to the Path header. When the flag isn't there, it 
means outbound is not supported by the proxy that inserted that Path header 
(hence no STUN poking)

> itself is not in the uri set)

I agree that the registrar wouldn't insert a Path header. So the rule should 
be: if there are Path headers, check if the last value contains a flag. If 
no Path headers, check for Supported : outbound (and start keepalives if 
found).

> So you won't be doing outbound when you should.

I think this is a matter of properly defining semantics. A flag in the Path 
header (or in the URI) would have to mean that the element supports STUN on 
all interfaces. It could be that the UAC cannot match the URI in the Path 
header to a host that it recognises / can reach, but I don't think it needs 
to. Just looking for the flag in the last Path header would suffice

Jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 29 Mar 2006 22:00:15 +0200

see inline

> potentially a re-usable concept for a future draft for a proxy-to-proxy

This was the gist of the idea I posted too. However, consider the following 
scenario:

UAC, P1, and the registrar all support outbound, P2 does not and also does 
not add a Path header. In this case, P1 should initiate a flow directly to 
the registrar, and keep it alive. However, keepalive support cannot be 
detected from the top Via header in the response, since that was added by 
P2!

In this particular case P1 could check for Supported : outbound and it could 
work (assuming you go along with proxies initiating new flows, which 
probably has security implications). However, then consider an additional 
proxy P3 in the scenario, and it would break once more.

Another issue with proxy-proxy keepalive is: how would the UAC be notified 
of flow failure?

Jeroen

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Mar 2006 17:30:20 -0800

Clearly discovering the proxy set is a separable problem from what to do
with it. As we agreed in the meeting, I would rather have these is separate
documents since we can move forward with the what you do with it now and
solve the many possible way beyond configuration how you might find it
later. I will point out that for most deployed SIP UA, the AOR is supplied
by some configuration system and not by the end user typing it in so there
are *some* systems that can work with configuration.

Cullen <always with my individual contributor hat on unless otherwise
specified :-)

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Mar 2006 17:50:40 -0800

> supports outbound before sending its REGISTER request?

So that we don't send things to the proxy that it does not understand. Some
people did not care about this - some felt strongly about it. Some pointed
out that the proxy might black list a client that seemed to be "attacking
it" with bogus packets.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 30 Mar 2006 08:07:53 +0200

> out that the proxy might black list a client that seemed to be "attacking

The people that feel strongly about this could add 'Require: outbound' to 
their request. Implementations that would blacklist such clients would be 
considered broken.

An alternative would perhaps be to depend on an authentication challenge: 
first send a normal REGISTER, challenge, respond to the challenge and if 
Supported: outbound is there modify the request as needed. Not common 
practice though...

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 30 Mar 2006 09:47:09 +0300

Cullen Jennings writes:

 > As we agreed in the meeting, I would rather have these is separate
 > later. 

it is fine to have a separate document describing how SIP UA finds
outbound-proxy-set, but that separate document MUST be referenced in the
outbound I-D in the same way as rfc3263 is referenced by rfc3261.  there
is no point to publish a document where the only standards based way to
configure outbound-proxy-set is manually, because no regular user is
able to do it correctly.

-- juha

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 30 Mar 2006 04:36:53 -0500

Hi Jeroen, see inline...

> Sent: Wednesday, March 29, 2006 3:00 PM
>

Huh?  I'm confused.  Why would P1 initiate a flow directly to P2?  The
keepalive is a socket ping, for UAC to P1 only.  You mean for proxy-proxy
keepalive?  I don't think that's in scope for sip-outbound.  I was just
mentioning that the Via check idea/concept could potentially be re-used for
a proxy-proxy, but I wasn't suggesting doing proxy-proxy for sip-outbound.

> Another issue with proxy-proxy keepalive is: how would the UAC be notified

Although this topic is out of scope of sip-outbound - my answer would be "it
wouldn't".  It's not an end-end keepalive mechanism, and it's a generic
proxy-to-proxy keepalive.  The socket may be between any proxies, and could
represent the link between 2 service providers connecting together millions
of UAs.  
But that's why it's been pushed out of sip-outbound I think - so we can
discuss the goals and issues later and get this one done and stun.  :)

-hadriel

---

From: <[email-masked]>
Date: Thu, 30 Mar 2006 12:54:42 +0300

Hi !

I still wonder if it would be sufficient for the UA to automatically
discover the proxies of certain domain, using NAPTR and SRV
queries just like before (as described in RFC 3263), IF there
is a way for the UA to detect the proxy and registrar support
for Outbound within the REGISTER - 200 OK exchange ? If there
is no Outbound support for the proxy the UA could potentially
unregister and try sending REGISTER via another proxy, even if
this kind of blind trying is not very efficient.

There are some proposals for the SIP based detection being
discussed, using mechanisms in either Via or Path headers.
If one of those will be accepted and written into Outbound
I-D, do we still need another mechanism to be specified ?

I have recently ralized that the mechanism I have been proposing
(new types of NAPTR records) suffers from a generic problem (which
I identified but did not take so seriously) as described in SigComp
related RFC 3486 as follows:

   A SIP [1] client sending a request to a SIP server typically performs
   a DNS lookup for the domain name of the server.  When NAPTR [4] or
   SRV [5] records are available for the server, the client can specify
   the type of service it wants.  The service in this context is the
   transport protocol to be used by SIP (e.g., UDP, TCP or SCTP).  A SIP
   server that supports, for instance, three different transport
   protocols, will have three different DNS entries.

   Since it is foreseen that the number of transport protocols supported
   by a particular application layer protocol is not going to grow
   dramatically, having a DNS entry per transport seems like a scalable
   enough solution.

   However, sometimes it is necessary to include new layers between the
   transport protocol and the application layer protocol.  Examples of
   these layers are transport layer security and compression.  If DNS
   was used to discover the availability of these layers for a
   particular server, the number of DNS entries needed for that server
   would grow dramatically.

   A server that, for example, supported TCP and SCTP as transports, TLS
   for transport security and SigComp for signaling compression, would
   need the 8 DNS entries listed below:

      1.   TCP, no security, no compression

      2.   TCP, no security, SigComp

      3.   TCP, TLS, no compression

      4.   TCP, TLS, SigComp

      5.   SCTP, no security, no compression

      6.   SCTP, no security, SigComp

      7.   SCTP, TLS, no compression

      8.   SCTP, TLS, SigComp

   It is clear that this way of using DNS is not scalable.  Therefore,
   an application layer mechanism to express support of signalling
   compression is needed.

Defining new NAPTR service types for Outbound would have exactly
similar effect.

Regards,

Erkki

>Sent: 30.March.2006 09:47
>To: Cullen Jennings
>Cc: [email-masked]; Niemi Aki (Nokia-NRC/Helsinki); Dean Willis
>Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt
>
>Cullen Jennings writes:
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 30 Mar 2006 05:31:25 -0500

Hi Jeroen,
The whole point is actually to make it a MUST that the UA perform a "safe"
check, where "safe" means a sip-compliant check, before it does anything
bad.  It cannot be a choice of a sip-outbound compliant UA to just do bad if
it wishes.  It's not actually the outbound sip changes that are the big
problem, it's really the binary/stun messages.

I'm not overly worried about anyone sending new sip signaling - of course
you can send that.  Every new draft/RFC does that, and the beauty of SIP is
to have that backwards-compatible flexibility.  If the new sip-signaling
needs to be understood by boxes that didn't have to understand it before
because they may create issues for the legacy sip "network", well that's a
problem from a SIP WG perspective I would think.  And that is also a problem
right now, perhaps, if a sip-outbound UA assumes the edge proxy is a
sip-outbound proxy, when it is not.  Right now the draft has no way to let
the UA know the edge-proxy supports outbound.  It has a way for it to know
the registrar does, although even then it doesn't say that knowledge must be
used for anything.  The results of that may lead to constant forking, which
is probably not a good thing.

But the REAL problem is the UA can send a binary message.  I understand why
we want to do that, and although I hated the idea at first, I am willing to
accept the decision and it's growing on me.  BUT, it's still a major issue
if UAs can send it when they like.  They MUST safely check to make sure it's
ok.

It's not a major issue for my company - our products will handle it fine.
But I can't speak for others.  And not everyone who makes a sip-compliant
proxy/registrar/UAS follows this mailing list.  And people have all kinds of
old software out there, which may be hard to upgrade.  One only needs to
look at the initial Protos test results to get an idea of the potential.

Do we really want CERT Advisories issued, and the root cause being the IETF
SIP Working Group???  Ironically, that would be good for firewall and SBC
vendors - but not good for SIP.  We have to do as much as possible to
prevent it.

-Hadriel

> Sent: Thursday, March 30, 2006 1:08 AM
> To: Cullen Jennings; Dean Willis; [email-masked]
> Cc: Juha Heinanen

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 30 Mar 2006 14:11:26 +0300

[email-masked] writes:

 > for Outbound within the REGISTER - 200 OK exchange ? 

erkki,

as klaus me and others have said, the new "outbound" NAPTR records bring
great value to SIP, because they allow local SIP UAs to detect a
different set of proxies than what foreign SIP UAs and proxies detect
using existing NAPTR records.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 30 Mar 2006 14:15:34 +0300

> Defining new NAPTR service types for Outbound would have exactly

it would about double the current number of records, but would also
bring the benefits i mentioned in my previous message.  it is hard to
envision how you could otherwise separate proxies for use by local SIP
UAs from proxies for use by other UAs and proxies.

-- juha

---

From: "Patrick Timmons" <[email-masked]>
Date: Fri, 31 Mar 2006 13:56:37 -0600

Why not require that the UA send an OPTIONS request to its outbound proxy
with Max-Forwards: 0?  This jibes with the recommendations put forth in RFC
3261 (sec. 11) regarding querying capabilities of proxies:

   Alternatively, a server receiving an OPTIONS request with a Max-
   Forwards header field value of 0 MAY respond to the request
   regardless of the Request-URI.

      This behavior is common with HTTP/1.1.  This behavior can be used
      as a "traceroute" functionality to check the capabilities of
      individual hop servers by sending a series of OPTIONS requests
      with incremented Max-Forwards values.

The edge proxy could reply to such a request with "Supported: outbound,
keepalive-stun", or something along these lines.

The registrar's support of sip-outbound could be queried similarly.  This
could be done either prior to, or immediately after initial registration.

pt.

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, March 30, 2006 4:31 AM
To: 'Jeroen van Bemmel'; 'Cullen Jennings'; 'Dean Willis'; [email-masked]
Cc: 'Juha Heinanen'
Subject: RE: [Sip] How to indicate during proxy discovery that
aproxysupports"outbound"

Hi Jeroen,

-Hadriel

> >> Could you explain why it is needed that the UA knows whether the 
> >> proxy supports outbound before sending its REGISTER request?
> >
> The people that feel strongly about this could add 'Require: outbound' 
> to their request. Implementations that would blacklist such clients 
> would be considered broken.
> 
> 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

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 31 Mar 2006 22:29:23 +0200

Patrick,

Benefit of that is that it's nice and simple, drawback is an extra 
roundtrip. If you're willing to risk an extra roundtrip, you could do 
slightly better by adding Proxy-Require: outbound to the request, and 
specify proxy behavior similar to RFC3329. In particular, the edge proxy 
would be required to remove the Proxy-Require header if it supports 
outbound, and then forward the request (although RFC3261 table 2 does not 
allow a proxy to remove a Proxy-Require header, that is what is done). A 
non-supporting proxy would respond with an error, and the request could be 
retried without outbound.

This approach would only give an extra roundtrip in case the edge proxy does 
not support outbound

Regards,

Jeroen

----- Original Message ----- 
From: "Patrick Timmons" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>; "'Jeroen van Bemmel'" 
<[email-masked]>; "'Cullen Jennings'" <[email-masked]>; "'Dean Willis'" 
<[email-masked]>; <[email-masked]>
Cc: "'Juha Heinanen'" <[email-masked]>
Sent: Friday, March 31, 2006 9:56 PM
Subject: RE: [Sip] How to indicate during proxy discovery that 
aproxysupports"outbound"

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 31 Mar 2006 14:53:02 -0800

> configure outbound-proxy-set is manually, because no regular user is

I think you and I mean different things by the word "configuration". I was
not suggesting that end users would be typing several URIs into a phone
using a 9 digit key pad - I completely agree with you that this would never
happen in any scaleable way.

---

From: Dean Willis <[email-masked]>
Date: Fri, 31 Mar 2006 16:53:33 -0600

On Mar 31, 2006, at 2:29 PM, Jeroen van Bemmel wrote:

> roundtrip. If you're willing to risk an extra roundtrip, you could  
> do slightly better by adding Proxy-Require: outbound to the  
> request, and specify proxy behavior similar to RFC3329. In  
> particular, the edge proxy would be required to remove the Proxy- 
> Require header if it supports outbound, and then forward the  
> request (although RFC3261 table 2 does not allow a proxy to remove  
> a Proxy-Require header, that is what is done). A non-supporting  
> proxy would respond with an error, and the request could be retried  
> without outbound.
>

Having a proxy eat a proxy-require seems as much of a violation of  
SIP as having a proxy ignore a proxy-require as the PING proponents  
proposed. Perhaps not a good idea from the perspective of protocol  
purity.

But the OPTIONS probe seems like it might work.

--
Dean

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 31 Mar 2006 18:15:17 -0500

I had the same thought about proxies eating Proxy-Require values. But then 
prompted by Jeroen's mention of RFC 3329, I took a look and found this in 
Section 2.3.1 on page 8.

   .... and the server is a proxy, it MUST remove the
   "sec-agree" value from both the Require and Proxy-Require header
   fields, and then remove the header fields if no values remain.

I seems reasonable to me that an extension that would use a Proxy-Require 
tag might only apply to the first-hop proxy, as is the case with Security 
Agreement and outbound (for the edge proxy behavior). It also seems 
reasonable to me that if no other proxies along the path need to understand 
the extension, that the proxy doing the extension could remove the tag from 
the Proxy-Require header.

Given the precedent set in RFC 3329, we should consider that option. For 
outbound, we need two option tags. One which corresponds to the first-hop 
edge proxy behavior (i.e. the STUN ping) that would be in a Proxy-Require 
header, and one which corresponds to the registrar behavior (sip-instance 
and reg-id's) that would be in the Require header.

cheers,
(-:bob

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

----- Original Message ----- 

>> would be required to remove the Proxy- Require header if it supports 
>> outbound, and then forward the  request (although RFC3261 table 2 does 
>> not allow a proxy to remove  a Proxy-Require header, that is what is 
>> done). A non-supporting  proxy would respond with an error, and the 
>> request could be retried  without outbound.
>>
>
> Having a proxy eat a proxy-require seems as much of a violation of  SIP as 
> having a proxy ignore a proxy-require as the PING proponents  proposed. 
> Perhaps not a good idea from the perspective of protocol  purity.
>

---

From: "Patrick Timmons" <[email-masked]>
Date: Fri, 31 Mar 2006 20:31:03 -0500

Jeroen -

Ah, I wasn't aware that RFC3329 legitimized stripping Proxy-Require headers
for edge proxies.  Thanks for the reference.

However -- in a general sense, the issue here is that the UA needs to know
specific features as they pertain to the topology of the network; i.e., that
the *edge* supports 'outbound'.  My sense is that it's perfectly reasonable
to think that there will be requirements for UAs to know specific features
of proxies that sit topologically off of the edge (?-CSCF, for example).  In
this case, the Proxy-Require technique breaks down... and we're left with
supporting two different methods for achieving (essentially) the same ends.

For features that are specific to the edge proxy like sec-agree and outbound
this approach clearly works at least as efficiently as an additional
round-trip.  I'm certainly not opposed to using the technique, since RFC3329
set the precedent that it is okay to do so.  But it seems that using OPTIONS
to query the options of a device is putting the protocol to its intended
use; as to whether this virtue is worth the extra round-trip is open for
debate I suppose.

Maybe I'll go back and read the archives -- this must have come up before
during the development of RFC3329, which was before my time.

pt.

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Friday, March 31, 2006 3:29 PM
To: Patrick Timmons; 'Hadriel Kaplan'; 'Cullen Jennings'; 'Dean Willis';
[email-masked]
Cc: 'Juha Heinanen'

Patrick,

Regards,

Jeroen

----- Original Message -----
From: "Patrick Timmons" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>; "'Jeroen van Bemmel'" 

> Why not require that the UA send an OPTIONS request to its outbound 
> proxy with Max-Forwards: 0?  This jibes with the recommendations put 
> forth in RFC
> The edge proxy could reply to such a request with "Supported: 
> outbound, keepalive-stun", or something along these lines.
>
> The registrar's support of sip-outbound could be queried similarly.  
> This could be done either prior to, or immediately after initial
registration.
> check, where "safe" means a sip-compliant check, before it does 
> anything bad.  It cannot be a choice of a sip-outbound compliant UA to 
> just do bad if it wishes.  It's not actually the outbound sip changes 
> that are the big problem, it's really the binary/stun messages.
>
> I'm not overly worried about anyone sending new sip signaling - of 
> course you can send that.  Every new draft/RFC does that, and the 
> beauty of SIP is to have that backwards-compatible flexibility.  If 
> the new sip-signaling needs to be understood by boxes that didn't have 
> to understand it before because they may create issues for the legacy 
> sip "network", well that's a problem from a SIP WG perspective I would 
> think.  And that is also a problem right now, perhaps, if a 
> sip-outbound UA assumes the edge proxy is a sip-outbound proxy, when 
> it is not.  Right now the draft has no way to let the UA know the 
> edge-proxy supports outbound.  It has a way for it to know the 
> registrar does, although even then it doesn't say that knowledge must 
> be used for anything.  The results of that may lead to constant 
> forking, which is probably not a good thing.
>
> But the REAL problem is the UA can send a binary message.  I 
> understand why we want to do that, and although I hated the idea at 
> first, I am willing to accept the decision and it's growing on me.  
> BUT, it's still a major issue if UAs can send it when they like.  They 
> MUST safely check to make sure it's ok.
>
> But I can't speak for others.  And not everyone who makes a 
> sip-compliant proxy/registrar/UAS follows this mailing list.  And 
> people have all kinds of old software out there, which may be hard to 
> upgrade.  One only needs to look at the initial Protos test results to 
> get an idea of the potential.
>
> Do we really want CERT Advisories issued, and the root cause being the 
> IETF SIP Working Group???  Ironically, that would be good for firewall 
> and SBC vendors - but not good for SIP.  We have to do as much as 
> possible to prevent it.
>
> -Hadriel
>
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 31 Mar 2006 23:23:45 -0500

> Sent: Friday, March 31, 2006 5:54 PM
> 

I thought we were trying to avoid that whole debate again, no?  :)

Considering everything else this draft changes, for proxies and registrars,
one can hardly talk about "violation of SIP" and "protocol purity".  ;)  
Nor did all PING proponents propose having a proxy ignore a proxy-require,
and they shouldn't have - it wouldn't have needed to.

-hadriel
p.s. I am now firmly a STUN believer, but I only joined this list recently
and read through the archive and when one looks at the argument exchange, in
hindsight I think it's fairly comical