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

From: Cullen Jennings <[email-masked]>
Date: Sat, 1 Jul 2006 18:02:18 -0700

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 raised
>
> 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? 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.

>
> 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.

>
> 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  
solves.

> 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.

> Regards,
> Jeroen

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: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> 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  
>> 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-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:
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-04.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-04.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-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
>> 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
>
>
> _______________________________________________
> 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

_______________________________________________
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: Sun, 2 Jul 2006 19:21:56 +0200

Cullen,

see inline

Best regards,

Jeroen

----- Original Message ----- 
From: "Cullen Jennings" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 02, 2006 3:02 AM
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt

>> 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 
>> raised
>>
>> 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 
unknown).

> 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.
>>
>

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 
Proxy-Require)

>> 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) ?

>
>> Regards,
>>
>> Jeroen
>
> 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.
>
>>> This draft is a work item of the Session Initiation Protocol  Working 
>>> Group of the IETF.
>>>
>>>   initiate TCP connections and send asynchronous UDP datagrams to  User
>>>   delivered on existing connections established by the User  Agent.  It
>>> [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
>>> Internet-Drafts are also available by anonymous FTP. Login with  the 
>>> username

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 2 Jul 2006 10:44:50 -0700

On Jul 2, 2006, at 10:21 AM, Jeroen van Bemmel wrote:

>>> 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 sympathetic to what you are saying as I had originally proposed  
that it be allowed to do this - I pointed out the a SIP server would  
reject the message. Lots of people felt strongly that we should not  
send STUN messages to SIP servers that did not support it. The issue  
came up in some WG meeting - there was strong consensus that we  
should not send keep alive to things that did not support them.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 2 Jul 2006 10:59:53 -0700

On Jul 2, 2006, at 10:21 AM, Jeroen van Bemmel wrote:

>>> 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.
>>>
>>>
>>
> 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

Well totally ignoring anything to do with outbound - I don't really  
see how this is different from when someone configure the proxy as  
foo.com when it is supposed to be bar.com

I do think it is important to get sip so that a user might configure  
an AOR name and password and everything else just happens but that is  
the point of the config framework. I agree configuration is a  
nightmare today and we need to make it easier.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 2 Jul 2006 20:41:33 +0200

>> 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
>
> Well totally ignoring anything to do with outbound - I don't really  see 
> how this is different from when someone configure the proxy as  foo.com 
> when it is supposed to be bar.com
>

Conceptually not so different, but there would be a good chance that foo.com 
would either accept nothing or SIP on common SIP ports. The problem is that 
STUN is sent to the same port. Were it a different port, then the risk would 
be much lower. The combination of non-SIP (even binary) and same port makes 
it troublesome.

> I do think it is important to get sip so that a user might configure  an 
> AOR name and password and everything else just happens but that is  the 
> point of the config framework. I agree configuration is a  nightmare today 
> and we need to make it easier.

Easier and more foolproof, and more easy to debug / trace when/where things 
go wrong. For all of this, explicit confirmation of outbound support helps.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 2 Jul 2006 22:10:10 +0200

> I'll let Rohan reply to this but I don't think I see what problem it 

There's another, more fundamental reason for this. The draft defines an 
option-tag which can occur in Supported, Require, Proxy-Require, and 
Unsupported headers. For each of these cases the semantics and expected 
behavior should be defined, either in this draft or implicitly (eg based on 
RFC3261)

Without stating otherwise, the default behavior for Proxy-Require would be: 
return 420 Bad Extension if not understood, else process as defined for that 
feature. In particular, for the current draft a proxy would not remove the 
Proxy-Require header from the request it forwards. So if an UAC adds 
Proxy-Require, it means that every proxy on the path must support it.

This is not required nor desired, hence we'd better state explicitly that a 
proxy needs to remove any Proxy-Require: outbound when forwarding

Regards,

Jeroen