Subject: RE: [Sip] Outbound and STUN Keep Alive

From: "Michael Procter" <[email-masked]>
Date: Mon, 20 Feb 2006 09:06:14 -0000

Cullen Jennings wrote:
> Agree with John. 
> 
> I've been trying to think about the details of the double 
> CRLF. It's hard to
> construct and exact case (that does not involve buggy 
> software) that would
> results in double CRLF with no transaction identifier getting 
> messed up due
> to lack of transaction identifier. I can't decide if the lack 
> of transaction
> id is a real problem or a theoretical one.

What about a compromise?  Use double CRLFs.  If there is any doubt
about the response (either no response within expected timeframe,
or unexpected response etc.), then generate an OPTIONS.

This means that almost all keepalive traffic uses the lightweight
double CRLF approach, but that in the event of a network anomaly,
a normal SIP method (no new methods required) can be used to
confirm the path.  If by some chance, a rogue double CRLF was
dropped or inserted into the stream, this normal method would also
flush it out, returning the stream to a known state.

This seems to combine the best of both worlds - a lightweight
approach for normal use, and a more robust system when you need it.

Regards,

Michael Procter

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Wed, 22 Feb 2006 08:39:14 -0800

> approach for normal use, and a more robust system when you need it.

That's and interesting idea. I think the problem I was concerned with was
not CRLF failing when the the connection was good but having CRLF succeed
when the connection was bad. I can't decide if this really is a problem or
not. It's hard to think of a practical example where the connection would be
bad yet the UA would continue to get CRLF that were queued up in the
connection.

---

From: Dean Willis <[email-masked]>
Date: Wed, 22 Feb 2006 12:54:23 -0600

> bad yet the UA would continue to get CRLF that were queued up in the

Ambient echoes of CRLF are a different problem from NAT reset detection.

Let's say that a NAT reboots, and you're suddenly sending CRLF  
through a new binding. Your old Contact won't work anymore. But the  
CRLF is getting passed to the server just fine via the new binding.

Does the server that you're sending CRLF to just continue to echo  
CRLF back at you? Or does it have some way of recognizing that it's  
suddenly getting CRLF echo requests from a partner from which it has  
no current registration and stop echoing CRLF at you?

--
Dean

---

From: "Gary Gan" <[email-masked]>
Date: Wed, 22 Feb 2006 14:24:47 -0500

Depending on the server implementation, but either way has problems. If the
echo comes back from the new binding, the UA would not know the NAT has
rebooted. That's what the STUN multiplexing tries to resolve, which actually
handles the binding comparison on the client side. If the server checks for
the client bindings, then the server needs to maintain the binding states of
all UA, either in memory or database. It uses server resource. I don't think
it scales.

Gary Gan
Clique Communications

---

From: "Gary Gan" <[email-masked]>
Date: Wed, 22 Feb 2006 15:05:41 -0500

[UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server　　　]
  |                           |A|    |   +　　　　　　　　　　　　|
  |------------STUN?--------->[T| -->[Multiplexed STUN server　]

I just wonder how the STUN solution works with the above scenario. With the
outbound proxy in the different IP behind the NAT, the STUN keep-alive would
not be valid since the NAT binding is between the outbound proxy and the SIP
server.

Gary Gan
Clique Communications, LLC

-----Original Message-----
From: Gary Gan [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2006 2:25 PM
To: 'Dean Willis'; 'Cullen Jennings'
Cc: [email-masked]; 'Francois Audet'; 'Chris Boulton'; 'Michael Procter';
[email-masked]; 'John Elwell'
Subject: RE: [Sip] Outbound and STUN Keep Alive

Gary Gan
Clique Communications

---

From: "Gary Gan" <[email-masked]>
Date: Wed, 22 Feb 2006 16:19:32 -0500

So, it is not a simple STUN protocol anymore. The outbound proxy needs to
know how to forward the STUN request/response. It is more like the PING
keepalive mechanism. But I like the light weight of the STUN. How do we
combine these two? 

Gary Gan
-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2006 4:04 PM
To: Gary Gan
Cc: 'Cullen Jennings'; [email-masked]
Subject: Re: [Sip] Outbound and STUN Keep Alive

On Feb 22, 2006, at 2:05 PM, Gary Gan wrote:

>   |                           |A|    |   +　　　　　　　　 
> 　　　　|

It doesn't.

Or, it does, only if the outbound proxy is engaging in STUN keepalive  
to the registrar, and does state matching to know to drop the STUN  
channel to the UA (forcing a re-register) if the STUN channel to the  
registrar breaks. To do this, the UA would be using multiplexed STUN  
to the outbound proxy, not through the NAT  to the registrar.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 22 Feb 2006 15:03:54 -0600

It doesn't.

--
Dean

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 23 Feb 2006 10:38:37 +0100

The first question is why would the UA be sending STUN requests. As far 
as that UA is concerned, there is no NAT (the UA can do a basic 
RFC1918). Note that for RTP, the situation a little different. But 
that's not what were are talking about here.

Hisham

---

From: "Gary Gan" <[email-masked]>
Date: Thu, 23 Feb 2006 09:08:27 -0500

Take a look at: draft-ietf-sip-outbound-01

Gary Gan

Hisham

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 23 Feb 2006 17:32:56 +0100

what about it? The closest I see in the diagram in section 3.4. I still 
don't see why the UA needs to do anything about that. The NAT is 
between the outbound proxy and registrar. That the outbound proxy 
problem. Why would the UA be sending keepalive messages to keep the NAT 
binding open?

Hisham

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 23 Feb 2006 08:28:20 -0800

Hi Gary,

On Feb 23, 2006, at 1:38, Hisham Khartabil wrote:
> The first question is why would the UA be sending STUN requests. As 
> far as that UA is concerned, there is no NAT (the UA can do a basic 

The UA is supposed to send STUN requests or SIP requests over a flow to 
the outbound proxy.  The outbound proxy responds directly to the STUN 
request and treats the SIP request normally according to the Route 
headers and Request-URI.  So the outbound proxy will forward most SIP 
traffic on to the registrar/proxy.  The UA processes the STUN responses 
by checking if the mapped address changes from the one used on the 
first STUN query over this flow.  If so, the NAT binding has changed 
(probably due to the NAT rebooting).

Hope this helps.  If you can come up with a few sentences that explains 
this better, please propose it to the authors.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 23 Feb 2006 08:40:34 -0800

Hi Hisham,

Perhaps I wasn't clear enough in my earlier message to Gary.  STUN 
messages sent by the UA never get past the outbound proxy, so they will 
not help discover any change in connectivity between the outbound proxy 
and its next hop, nor will any other part of the outbound spec deal 
with connectivity between the outbound proxy and its next hop.  Dealing 
with NATs between proxies was never a requirement of this particular 
draft.

thanks,
-rohan

On Feb 23, 2006, at 8:32, Hisham Khartabil wrote:
> what about it? The closest I see in the diagram in section 3.4. I 
> still don't see why the UA needs to do anything about that. The NAT is 
> problem. Why would the UA be sending keepalive messages to keep the 
> NAT binding open?
>
> Hisham
>
>>> far
>>> outbound proxy in the different IP behind the NAT, the STUN 
>>> keep-alive
>>> would
>>> all UA, either in memory or database. It uses server resource. I 
>>> don't
>>> think
>>> it scales.
>>>
>>> Gary Gan
>>> Clique Communications
>>>
>>>

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 23 Feb 2006 18:23:43 +0100

Rohan,

That's what I'm trying to explain to Gary.

BTW, I never got that reply. Did u send it to the list?

Hisham
On Feb 23, 2006, at 5:40 PM, Rohan Mahy wrote:

> messages sent by the UA never get past the outbound proxy, so they 
> will not help discover any change in connectivity between the outbound 
> proxy and its next hop, nor will any other part of the outbound spec 
> deal with connectivity between the outbound proxy and its next hop.  
> Dealing with NATs between proxies was never a requirement of this 
> particular draft.
>
> thanks,
> -rohan
>
>
>
>> still don't see why the UA needs to do anything about that. The NAT 
>> is between the outbound proxy and registrar. That the outbound proxy

---

From: "Gary Gan" <[email-masked]>
Date: Thu, 23 Feb 2006 13:23:19 -0500

That is also my doubt. To simply use STUN multiplexing SIP port for
keepalive may not work.

Gary Gan

---

From: Dean Willis <[email-masked]>
Date: Thu, 23 Feb 2006 15:16:30 -0600

> with NATs between proxies was never a requirement of this particular

I think you guys are missing Gary's use case.

He's postulating an entirely different NAT problem, where the NAT is between 
the outbound proxy and the real world, rather than between the UA and its 
outbound proxy.

This just isn't a use case that's been in scope for general discussion so far. 
I'm not sure it needs to be -- it's a pretty freaky use case. 

Perhaps we might seee something like this in a small office, where there's an 
internal proxy-registrar that serves communications inside the firewall, but 
that then relies on an external proxy for routing calls outside the 
enterprise. This would require something like proxy-proxy connection reuse, 
or a port-forward rule on the firewall NAT, etc. to handle inbound calls.

In this case, sending STUN requests (multiplexed or otherwise) from the UA to 
the outbound proxy accomplishes nothing useful, or at least nothing usefu 
lwith respect to NAT traversal. 

Instead, we would need the "outbound proxy" to itself implement a version of 
the "outbound draft" to the next-hop proxy, because there is a NAT binding 
between the user's outbound proxy and the user's outbound proxy's outbound 
proxy. Thus, we might see STUN used inter-proxy.

The UA COULD also use STUN independently to a STUN server outside the NAT to 
discover the NAT's behavior, and possibly discover the UA's external address, 
which it would use in the construction of SDP.

--
Dean

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 24 Feb 2006 11:44:44 +0100

On Feb 23, 2006, at 10:16 PM, Dean Willis wrote:

>> will

This is addressed in section 3.4 of the draft (using path header). 
Isn't it?

Hisham

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Feb 2006 10:54:52 -0800

> This just isn't a use case that's been in scope for general discussion so far.

If I understand correctly ... I thin I added this use case to the document
awhile back because some people request it. For some vague reason, I thought
Dean was one of the people that had requested it. People had brought up
system like the ingate stuff. If the use case complicated stuff, I would
remove it but so far the baseline the simple case has pretty much solved
this one too.

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Feb 2006 15:47:24 -0600

> remove it but so far the baseline the simple case has pretty much  

Yep, I motivated the use case at one point.

However, what you have in 3.4 isn't quite what what Gary seemed to be  
looking at, in that:

1) 3.4 shows another NAT between the UA and the EP. This doesn't make  
the use case of 3.4 weaker, but might lead people to think that it is  
a different problem, when this aspect is really a more-general  
variant of Gary's case.

2) 3.4 does not seem show the use of "classic STUN" to discover the  
effective IP address for RTP, along a path disparate from the coaxial  
STUN used as a NAT keepalive. This is implied in the text, and is  
obvious from STUN itself, but might not be obvious to somebody who  
hasn't been thinking about this for a long time.

3) The use of coaxial STUN between the EP and the registrar, though  
implied in 3.4, also doesn't seem obvious in the text. Nor is the  
requirement for "back pressure" from the EP to the UA, should the EP- 
Registrar coaxial STUN indicate a reset of the NAT between those  
nodes. If this happens, I think that EP needs to induce a "keepalive  
failure" on its own channel back to UA. You talk about UAs detecting  
flow failure, but not about proxies detecting flow failure. Maybe it  
is in there and I just missed it . . .

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Feb 2006 21:47:06 -0800

> is in there and I just missed it . . .

Yep - I see what you are saying. I will try and clarify the draft a bit.

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 26 Feb 2006 15:13:09 -0800

Hi,

If my recollection is correct, I think we decided that use cases of 
NATs between proxies is out of scope of *this* document and that we can 
work on the (probably harder) proxy to proxy problem in *another* 
document so we can solve the more pressing problem sooner.

In any case, the proxy to proxy case is not explicitly listed in the 
requirements anywhere.

thanks,
-rohan

---

From: "Michael Slavitch" <[email-masked]>
Date: Sun, 26 Feb 2006 20:20:55 -0500

I am not sure why it is a harder problem. It is a question of actions that happen between peer agents, in this case one agent just happens to be a proxy, and in the other case both agents are proxies. I can see why it was not in the original scope of requirements, but now that it's been alerted it gives me pause that there is resistence in putting it in. Proxies should be able to go anywhere in the same way that agents should be able to go anywhere.

Do people really consider proxies something so special that they deserve special treatment, and are things SIP-wise separate from user agents? If so then SIP has changed from what it used to be and is losing its simple distributed nature and becoming something that seems increasingly monolithic.

Regards

M

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Sun 26/02/2006 6:13 PM
To: Cullen Jennings
Cc: [email-masked]; Dean Willis
Subject: Re: [Sip] Outbound and STUN Keep Alive
 
Hi,

thanks,
-rohan

-- 

-----------------------------------------------

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp.

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 26 Feb 2006 17:48:03 -0800

Hi Michael,

First of all, proxies don't register. The way outbound works now, new 
requests toward the UA go over an existing connection because of 
information provided during registration.  A mechanism for proxy-proxy 
outbound only connections is likely to require an unrelated mechanism.

Second, there are already rules in RFC 3261 and RFC 3263 for how to 
route from one proxy to the next. These rules assume that a proxy 
server is accessible.  This is not an especially radical concept.  HTTP 
assumes that HTTP servers are accessible and this did not turn out to 
be a huge barrier for most web sites.

Third, if a UA is sending traffic through a proxy, then a NAT, then a 
proxy, I ask why the UA bothered to send its SIP traffic through the 
first proxy instead of directly to the publicly accessible proxy? What 
service is being provided?  Recall that it is perfectly appropriate for 
a UA to be registered with multiple AORs in different domains.  In the 
case of a collocated proxy/NAT/FW, the purpose of sending through the 
first proxy is supposed to be NAT and firewall traversal.  The very 
purpose of outbound is to provide a mechanism for UAs so they do not 
require the help of such a NAT/FW.

Finally, the *title* of the draft says "User Agent initiated 
connections".

While I can still see valid use cases for proxy to proxy outbound 
connections, it seems clear to me that such a mechanism will a) be a 
different mechanism, b) require non-trivial changes to languages in the 
core spec, and c) need better use cases and requirements.

Hope this helps.
thanks,
-rohan

On Feb 26, 2006, at 17:20, Michael Slavitch wrote:
>
> I am not sure why it is a harder problem. It is a question of actions 
> that happen between peer agents, in this case one agent just happens 
> to be a proxy, and in the other case both agents are proxies. I can 
> see why it was not in the original scope of requirements, but now that 
> it's been alerted it gives me pause that there is resistence in 
> putting it in. Proxies should be able to go anywhere in the same way 
> that agents should be able to go anywhere.
>
>  Do people really consider proxies something so special that they 
> deserve special treatment, and are things SIP-wise separate from user 
> agents? If so then SIP has changed from what it used to be and is 
> losing its simple distributed nature and becoming something that seems 
> increasingly monolithic.
>
>  Regards
>
>  M
>
>
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and 
> delete this information from your system. Use, dissemination, 
> distribution, or reproduction of this transmission by unintended 
> recipients is not authorized and may be unlawful.
>
> Any views, opinions and content presented in this e-mail are solely 
> those of the author and may not represent those of Objectworld 
> Communications Corp.
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 26 Feb 2006 19:20:44 -0800

I think the hard part is that when the inner proxy detects the NAT between
the inter and out proxy has rebooted, it needs a way to tell all the UA to
re-register. It's not that I don't want to solve this, is just that I think
the solution to this can be solved separately from the minimal stuff that
needs to be outbound.

On 2/26/06 5:20 PM, "Michael Slavitch" <[email-masked]> wrote:

> 
> 
> I am not sure why it is a harder problem. It is a question of actions that
> happen between peer agents, in this case one agent just happens to be a proxy,
> and in the other case both agents are proxies. I can see why it was not in the
> original scope of requirements, but now that it's been alerted it gives me
> pause that there is resistence in putting it in. Proxies should be able to go
> anywhere in the same way that agents should be able to go anywhere.
> 
> Do people really consider proxies something so special that they deserve
> special treatment, and are things SIP-wise separate from user agents? If so
> then SIP has changed from what it used to be and is losing its simple
> distributed nature and becoming something that seems increasingly monolithic.
> 
> Regards
> 
> M
> 
> 
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this transmission
> by unintended recipients is not authorized and may be unlawful.
> 
> Any views, opinions and content presented in this e-mail are solely those of
> the author and may not represent those of Objectworld Communications Corp.
>