Re: I-D ACTION:draft-ietf-sip-outbound-04.txt
Jeroen van Bemmel <jbemmel <at> zonnet.nl>
2006-07-02 17:21:56 GMT
----- Original Message -----
From: "Cullen Jennings" <fluffy <at> cisco.com>
To: "Jeroen van Bemmel" <jbemmel <at> zonnet.nl>
Cc: <sip <at> ietf.org>
Sent: Sunday, July 02, 2006 3:02 AM
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt
> On Jun 29, 2006, at 3:28 PM, Jeroen van Bemmel wrote:
>> We've had some VERY long and extensive discussions on this (starting
>> with http://www1.ietf.org/mail-archive/web/sip/current/ msg13677.html)
>> but the draft is still not addressing some of the issues that were
>> 1) The UAC needs a positive indication that the selected proxy can
>> indeed handle STUN packets without choking on them. It is not sufficient
>> if the URI it is configured with says 'keepalive=stun', that's a wish
>> but no guarantee.
> Why is this a wish not a guarantee?
Because the configuration may be wrong, ie the entity that provisioned the
URI thinks the element supports outbound, but in fact it does not. There can
be various reasons for this, like invalid manual provisioning, some edge
proxy is replaced with one that does not support outbound and someone
forgets to update DNS, etc
I expect you will see a lot of what I'd call "opportunistic outbound":
implementations that add 'keepalive=stun' to the URI for registration, in
the hope that it is supported. There is nothing in the current spec to
prevent this, but I believe it should be discouraged (that is, the sending
of STUN packets multiplexed on SIP ports to hosts for which support is
> I'm under the impression that devices that follow the RFCs should not
> have problems with this. I understand the argument that we might want
> DHCP or DNS to be a way to discover this configuration information but I
> think either of theses systems, not to mention the config-framework, can
> be used to get an URI. Keep in mind the thing that drove us to this
> approach - sig- comp. We need sig-comp to work too so however we deal with
> the approach for configuration of the URI so it has the sig-comp tag will
> also work for this. These options were discussed several times - at one
> point I was proposing a DNS scheme but I got the input that it could and
> should be separated.
I suppose a similar argument applies to sigcomp: it should have been
prevented that implementations try it towards hosts that are not known to
support it. A difference may be that sigcomp is also used in the first
request, while STUN can be postponed
A second reason for providing such a 'keepalive confirmation' is that it
also allows cases where the registrar / edge proxy is able to determine that
keep-alives are in fact not needed (eg because it has authorative knowledge
that there is no NAT or firewall in between). Not including 'keepalive=stun'
would avoid unnecessary traffic. (note that perhaps a different mechanism
would be more appropriate, eg "keepalive=not-needed" instead, to distinguish
between not supported and not needed)
>> 2) Section 5.3: the Edge Proxy MUST Record-Route dialog forming INVITE
>> requests that it forwards over the flow towards the UA (reverse
>> direction is not strictly necessary, but probably common too). If it
>> does not do this, an ACK for 2xx cannot arrive. For incoming SUBSCRIBE
>> it might work without (the NOTIFY could create a direct flow towards the
>> target or some other proxy, using the local socket as a Contact), but
>> then there would be an issue with keeping that flow alive (the STUN
>> question). Probably safer to say that (in addition to MUST for INVITE)
>> "the Edge Proxy SHOULD Record-Route all dialog-forming requests it
>> forwards to the UA"
> This could be one way to solve the problem - others are possible too. I
> don't think this is in scope for outbound. I don't think outbound does
> anything that makes it so this solution (or some of the other proposed
> ones) can't be used. A long time ago, outbound got stuck in a huge rat
> hole of trying to define how every system should form it's high
> reliability and high availability solutions. That was too big a task to
> take on so I am happy to leave it out of scope as long as people can
> build good system.
I agree that the way in which high reliability/availability is done should
be left to implementations. However, I don't see how ACK for 2xx could
arrive without Record-Route (the contents of the R-R URI, and wheteher it is
used for flow mapping is an implementation issue. However, I think its use
should be mandated).
>> 3) The Proxy-Require mechanism we have discussed could be useful to UACs
>> that want to ensure that a selected edge proxy supports outbound,
>> aborting if not.
> I'll let Rohan reply to this but I don't think I see what problem it
It ensures early abortion of the registration process if outbound is not
supported. As it is currently defined, a UAC has no way of determining
whether an edge-proxy supports outbound (the flag in the provisioned URI
makes it very likely, but not guaranteed)
A second usage of a Proxy-Require mechanism is perhaps out of scope for
outbound, but related to keep-alive (which, as others have pointed out,
should perhaps be separated). Consider an UAC behind NAT that sends an
INVITE. Note that it could manage perfectly well without outbound support
(it could simply not REGISTER), but it would need to keep the flow towards
its peer open. If it is somehow able to determine that the peer does not
support STUN, and it cannot use TCP keepalive, what should it do? One way
could be to ask a proxy that supports keepalives to stay in the signaling
path. It need not be the same proxy used for registration (but it might well
be). For this scenario, the UAC would need a way to ask the proxy to provide
keep-alive services. "Proxy-Require: keep-alive" would be one way; semantics
would be that the proxy MUST Record-Route such a request (as discussed in a
parallel thread, another reason is that the ACK might contain the same
>> 4) (minor remark) Perhaps some words could be added that the UAC SHOULD
>> perform keepalives when configured to do so, even if it detects that
>> there is no NAT. There could be a transparent firewall device that needs
>> to be kept open.
> I agree this is the behavior we want - I thought it already more or less
> said that. It does not suggest detecting if their is a NAT there at
> all - if the URI has the tag, you do keep alive.
and if there is no such tag, it MUST NOT do keep alive (or at least not
STUN, TCP keepalives would be harmless) ?
> I'm sorry my time is limited on this right now but I'm reading a ton of
> documents and posting comments so forgive me as I suffer from a response
> implosion problem.
> Cullen <my crazy comments as an individual only>
>> ----- Original Message ----- From: <Internet-Drafts <at> ietf.org>
>> To: <i-d-announce <at> ietf.org>
>> Cc: <sip <at> ietf.org>
>> Sent: Wednesday, June 28, 2006 12:50 AM
>> Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> 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-04.txt
>>> Pages : 34
>>> Date : 2006-6-27
>>> The 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. 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:
>>> To remove yourself from the I-D Announcement list, send a message to
>>> i-d-announce-request <at> ietf.org 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
>>> "anonymous" and a password of your e-mail address. After logging in,
>>> type "cd internet-drafts" and then
>>> "get draft-ietf-sip-outbound-04.txt".
>>> A list of Internet-Drafts directories can be found in
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>> Internet-Drafts can also be obtained by e-mail.
>>> Send a message to:
>>> mailserv <at> ietf.org.
>>> In the body type:
>>> "FILE /internet-drafts/draft-ietf-sip-outbound-04.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
>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol
>>> Use sip-implementors <at> cs.columbia.edu for questions on current sip
>>> Use sipping <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
>> Use sipping <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip