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

From: "Chris Boulton" <[email-masked]>
Date: Mon, 13 Feb 2006 11:14:41 -0000

First questions is, does Double CRLF work?

[Chris Boulton] The fact that you need to ask that questions makes me a
little uneasy :-).

Second questions is, given we have to do STUN for UDP, would we want to
do
something different for TCP?

[Chris Boulton] If it works for UDP then lets just use it and keep it
consistent.

_______________________________________________
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

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

_______________________________________________
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: "Michael Slavitch" <[email-masked]>
Date: Mon, 13 Feb 2006 10:23:35 -0500

It depends on the hardware abstraction layer. In other words: not
always, so probably not enough.

It is amazing what you can accomplish if you do not care who gets the
credit. 
 
- Harry S Truman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Boulton
Sent: February 13, 2006 6:15 AM
To: Cullen Jennings; [email-masked]
Subject: RE: [Sip] Outbound and STUN Keep Alive

Second questions is, given we have to do STUN for UDP, would we want to
do something different for TCP?

_______________________________________________
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

Information contained in this e-mail and any attachments are intended
for the use of the addressee only, and may contain confidential
information of Ubiquity Software Corporation.  All unauthorized use,
disclosure or distribution is strictly prohibited.  If you are not the
addressee, please notify the sender immediately and destroy all copies
of this email.  Unless otherwise expressly agreed in writing signed by
an officer of Ubiquity Software Corporation, nothing in this
communication shall be deemed to be legally binding.  Thank you.

_______________________________________________
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

--

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

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: [email-masked]
Date: Wed, 15 Feb 2006 19:52:12 -0600

I posted the PING draft to the IETF site for posterity.  I mailed it tonite, not sure when it will show up on the site.

FM

------------------------------------------------
On Wed, 15 Feb 2006 19:22:34 -0600, "Francois Audet" <[email-masked]> wrote:

> Exactly my view.
> 
> I really don't see why processing a PING method would be any more
> resource-intensive because of "parsing" or whatever than processing
> a STUN message (binary) that happens to run on the same port
> the rest of the SIP protocol runs on.
> 
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Hisham Khartabil
> > Sent: Wednesday, February 15, 2006 05:16
> > To: Cullen Jennings
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [Sip] Outbound and STUN Keep Alive
> > 
> > 
> > This is all theory and guesstimates. We'll try to prototype these 
> > things and get back to the list with hard numbers to prove or 
> > disprove 
> > the 2 theories. If anyone willing to co-operate on this, 
> > please contact 
> > me.
> > 
> > Regards,
> > Hisham
>

---

From: "Bharrat, Shaun" <[email-masked]>
Date: Thu, 16 Feb 2006 07:48:01 -0500

Audet, Frank:

We have in the recent past implemented three refresh variants 
on an embedded platform:
1. Full parse of REGISTER with an immediate 200 (C stack)
2. "Fast parse" of a REGISTER looking only for To/From/Via/CSeq
and sending a register using those fields (again C code)
3. STUN server which only supported the requests without port or
address change subrequests (again C code).

#3 was almost an order of magnitude better than #1 and about 3 times
as fast as #2. 

So why is #2 slower at all -- unless you have really nifty pattern
matching h/w, you have to go through byte-by-byte (at least once)
to find the To/From/Via/CSeq. A STUN packet is both tiny and you can
quickly skip over irrelevant data.

If you do ever end up declaring "you SHOULD use REGISTER, PING, OPTIONS 
or some other SIP message to do refresh", please don't take away 
the STUN option from those for whom 3x is a _big_ deal.

Thanks and cheers,
Shaun

Sonus Networks
www.sonusnet.com

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Francois Audet
> Sent: Wednesday, February 15, 2006 8:23 PM
> To: Hisham Khartabil; Cullen Jennings

---

From: "Bharrat, Shaun" <[email-masked]>
Date: Thu, 16 Feb 2006 08:05:56 -0500

One slight correction. In #1, the application got involved so
it is not an immediate 200. A 200 from directly in the stack
was not measured. The useful comparison, IMO, is #3 to #2.

Thanks and cheers,
Shaun Bharrat

Sonus Networks
www.sonusnet.com

> Bharrat, Shaun
> Sent: Thursday, February 16, 2006 7:48 AM
> To: Francois Audet; Hisham Khartabil; Cullen Jennings

---

From: "Steve Langstaff" <[email-masked]>
Date: Thu, 16 Feb 2006 13:23:14 -0000

Isn't that figure of 3.8bps more like:

(20 + 36) * 8 / 15  (= 30bps) for STUN

vs

(300 + 300) * 8 / 15 (=320bps) for OPTIONS

[i.e. approximately 9% of the bandwidth]

or does STUN use a different timeout to OPTIONS?

If we *do* take IP/UDP overheads into account, but not link headers, we get:

(20 + 36 + 28 + 28) * 8 / 15 (~= 60bps) for STUN

vs

(300 + 300 + 28 + 28) * 8 / 15 (~= 350bps) for OPTIONS

[i.e. approximately 17% of the bandwidth]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jonathan Rosenberg
Sent: 15 February 2006 17:05
To: Pekka Pessi
Cc: Cullen Jennings; [email-masked]; [email-masked]; Dean Willis
Subject: Re: [Sip] Outbound and STUN Keep Alive

The bandwidth aspect of this is important too. The STUN request in 
question here is 20 bytes, and the response is 36. A SIP OPTIONS request 
and response is probably around 300-400 bytes. At a rate of a keepalive 
every 15 seconds, you end up with 320 bps per subscriber for OPTIONS, 
and 3.8 bps for STUN (not counting IP/UDP overheads). Its interesting to 
compare this to 'useful' traffic. Assuming .1 erlangs and a hold time of 
3m during the busy hour, you get 5.5e-4 calls per second per subscriber. 
With a INV/200/ACK BYE/200 sequence, and assuming 1kB for INV/200 and 
300B for the others, thats 2.9 kB total per call, and thus 12.76 bps per 
subscriber. As a consequence, with the OPTIONS approach, you have a 
bandwidth overhead of 320/12.76 which is 25, or 2500%!!!! WIth STUN, 
this is a still painful but palatable 3.8/12.76 = 30%.

To put that in perspective, a server supporting 100k subscribers would 
require 1.2 Mbps access for useful signaling, and an additional 32 Mbps 
just for the useless OPTIONS message. To make sure you are nowhere near 
(i.e. not within 50%) of link saturation, this comes close enough to the 
limit of 100M ethernet that you'd probably need to jump to GiGE, whereas 
10M ethernet would suffice with STUN keepalives.

-Jonathan R.

Pekka Pessi wrote:

> Dean Willis <[email-masked]> writes:
> 
>>[email-masked] wrote:
>>
>>>will OPTIONS method not work for the same? Instead of sending an CRLF we
>>>can also send an OPTIONS method to refresh the NAT binding. If i am not
>>>wrong then OPTIONS method was discared because of the processing of the
>>>SIP message for keeeping the NAT binding alive. Hence, CRLF was
>>>considered. But CRLF is not backward compatible i.e. it does not provide
>>>MAPPED ADDRESS. Now bringing in the PING method would again be introducing
>>>a SIP message based processing which would lead to poor performance.
> 
> 
>>We've demonstrated successfully slaying proxies by bombing them with OPTIONS
>>requests.
> 
> 
>>Back in the "early days" of dynamicsoft, our first proxies were processing 7
>>INVITE/200/ACK/BYE/200 non-authenticated transaction sequences or about 20
>>OPTIONS transactions per second. They've of course gotten much faster, but
>>the proportions have stayed pretty much the same.
> 
> 
>>So you can see that in models where a typical SIP transaction load might be
>>5 transactions per hour per node, adding another 60 OPTIONS transactions per
>>hour per node might reduce your edge-proxy scalability by on the order of
>>13-1, or roughly a 93% performance hit. That's a big hit.
> 
> 
> Of course, that is the relative performance hit that you will see
> on a 100 Mb/s ethernet, which I think is the bottleneck on most
> SIP servers. You do lot of OPTIONS, you use all you bandwidth
> receiving OPTIONS, right? ;-)
> 
> On more serious discussion, you use roughly the same number of
> packets and system calls to process a STUN request as when
> processing OPTIONS, The bottleneck is not in the CPU doing SIP or
> STUN parsing but (hopefully) somewhere else, like your memory bus
> or network I/O. Both SIP and STUN parser and processing code fit
> nicely in your cache nowadays, mixed STUN/SIP server losing
> because it has to fit both SIP and STUN parser code in its cache.
> 
> Of course, a hypothetical SIP server implemented in Perl and
> heavily relying in shell scripting might be a different story.
> 
> --Pekka
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: [email-masked]
Date: Fri, 17 Feb 2006 18:40:20 +0200

Brian, et. al-

Please excuse me a stupid question: how much does the approach
suggested below really differ from multiplexing two different
protocols (like SIP and STUN) to the same port ? To me it would
look like that this PING would already introduce its own protocol
with its own parsing and processing rules, at least for the server
receiving PING requests.

On Feb 15, 2006, at 10:10 PM, Brian Stucker wrote:

> Dean, et. al-
>
> Keep in mind one thing in your calculations... 
> Parsing a MESSAGE that is short (which may or may 
> not be a message that needs further processing) 
> cannot be separated from "service" traffic as easily 
> as PING. Once I've parsed the request type I immediately 
> know that I'm dealing with a special case and can shunt 
> processing over to a separate chunk of code that can 
> ignore much of the message.
>
>
> For instance, here would be a very simple way of parsing a PING:
> 
> 1. Is the request type of the message "PING". If so, then shunt...
> 2. In the shunt parser take the original packet the PING came in on 
> and do the following:
> Replace the top of the buffer from "PING sip:xxxyyyzzz... SIP/2.0" 
> to "SIP/2.0 200". Pad the remainder with white space until you hit 
> the CRLF that terminates the request URI.
> 3. Append the correct header information to bottom of the packet 
> to identify the source of the request.
> 4. Send the packet back from whence it came.
>
> (Potentially) no data that needs to be copied and nothing other 
> than the first five characters of the message needs to be parsed.

Regards,

Erkki

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 17 Feb 2006 14:16:20 -0600

You can key on the "PING" at the begining of the packet (in 
a fixed location, just like the STUN alternative), and bypass
all the normal SIP processing IF you need to "optimize".

> Behalf Of Cullen Jennings
> Sent: Tuesday, February 14, 2006 08:01
> To: [email-masked]; Dean Willis
> Cc: [email-masked]
> I don't see any reason that the PING will work better than 
> just sending OPTIONS
> 
> On 2/13/06 6:06 PM, "Frank W. Miller" <[email-masked]> wrote:
> 
> > 
> > I took the liberty of putting together a new draft that 
> proposes the 
> > PING method.  The draft is at http://www.cornfed.com/ping.txt.  
> > Comments welcome!
> > 
> > FM
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Feb 2006 15:40:48 -0500

No, of course not.

It becomes a different protocol when you make exceptions to normal SIP 
processing rules because of the method. I believe it would be contrary 
to the intent of the spec, for example, to specify that, for a 
particular new method, Proxy-Require is not permitted.

-Jonathan R.

Brian Stucker wrote:

> I don't follow...
> 
> Lazy parsing a SIP message turns the message into a different protocol from SIP?
> 
> Regards,
> Brian
> 
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, February 17, 2006 10:57 AM
> To: Thomas Froment
> Cc: Stucker, Brian [RICH1:B620:EXCH]; [email-masked]
> Actually, having a special code path that processes this SIP PING in a 
> fundamentally different way is worse, IMHO. You are not only basically 
> muxing a separate protocol on the same port anyway, you are breaking SIP 
> by applying non-standard processing to it. I think you stand a much 
> worse chance of interop failures with an implementation that processes 
> SIP in a non-standard way. A client might send a PING, assuming it gets 
> processed correctly, and then gets surprised when its basically being 
> treated like a STUN request formatted as a sip mesage. How about we just 
> send that stun request in the first place.
> 
> -Jonathan R.
> 
> Thomas Froment wrote:
> 
> 
>>Brian Stucker wrote:
>>
>>
>>>How can you send a 200 OK without parsing out the Via header fields?
>>>How do you get the cseq without parsing that out?
>>>
>>>-- Don't. Send the message back where it came from using the transport 
>>>information in the packet and reuse the existing information in the 
>>>request to form a valid response. You only need to add information to 
>>>the end of the packet (in the form of a message body or header) to 
>>>report what you saw from the UA in terms of their observed network 
>>>address.
>>>
>>>Very fast. Of course the UA gets to eat it's own dog food if it sends 
>>>something bad in the request.
>>> 
>>>
>>
>>If you don't look at Via header to answer a SIP request, and just send a 
>>"packet" back to the source IP Address/port, you are not doing SIP anymore,
>>you are doing a "hack". In this case, this is no more "clean" than 
>>double CR/LF or STUN.
>>Just to insist a last time on this topic: the most important point for 
>>me is *consistency* with other parts of sip-outbound draft, as Chris 
>>mentionned: "It is already specified for UDP in the Outbound draft", so 
>>why not use the same thing for TCP?
>>
>>
>>
>>

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 17 Feb 2006 15:17:12 -0600

SIP Message grammar insures that method name is at the fixed location in
the transport payload.

  SIP-message = Request / Response 
  Request = Request-Line *( message-header ) CRLF [ message-body ] 
  Request-Line = Method SP Request-URI SP SIP-Version CRLF 

No other characters, Optimization works well with RFC compliant clients.

Thx
Samir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Audet, Francois [SC100:9T51:EXCH]
Sent: Friday, February 17, 2006 12:16 PM
To: Cullen Jennings; [email-masked]; Dean Willis
Cc: [email-masked]
Subject: RE: [Sip] Outbound and STUN Keep Alive

You can key on the "PING" at the begining of the packet (in a fixed
location, just like the STUN alternative), and bypass all the normal SIP
processing IF you need to "optimize".

> Cullen Jennings
> I don't see any reason that the PING will work better than just 
> sending OPTIONS
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 17 Feb 2006 16:05:08 -0600

In-line.
-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, February 17, 2006 1:42 PM
To: Srivastava, Samir [SC100:8826:EXCH]
Cc: Jonathan Rosenberg; Thomas Froment; [email-masked]; Stucker, Brian
[RICH1:B620:EXCH]

On Feb 17, 2006, at 2:51 PM, Samir Srivastava wrote:

> If client gets the response it is expecting, there is no issue. What 
> else it is expecting on the PING, pl Clarify. Server is free to 
> optimize.

And what if some future extension uses a Proxy-Require or such to
enforce some other extension behavior, but we don't process the new
Proxy-Require because we're not parsing the whole SIP message?

SS>> PING is special purpose method intended for KEEP-ALIVE only. It
should not be having any other feature 
negotitation embedded in. PING should not be having these proxy-require
etc. All headers are not applicable 
to all methods. This is new method to be defined, we have a control over
the headers that are applicable to it.
To find the features set/extensions use the existing OPTIONS.

Breaks the SIP feature-negotiation model.

Danger, Will Robinson!

--
Dean

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 22 Feb 2006 12:04:14 -0500

We've seen this in our testing on commodity NAT equipment. 

It isn't theoretical. This is a regular occurrence and will happen with
current devices in the field. 

- Harry S Truman

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: February 22, 2006 11:46 AM
To: [email-masked]; Hisham Khartabil; [email-masked]
Cc: [email-masked]; Francois Audet; [email-masked]; Dean Willis
Subject: Re: [Sip] Outbound and STUN Keep Alive

On 2/21/06 11:23 PM, "[email-masked]"
<[email-masked]>
wrote:

> Hi ! 
> 
>> Forget about the CRLF for UDP as well. It does not have the feature 
>> that solves the rebooting NAT problem.
> 
> What about the following approach (at least as a short term solution 
> while the ultimate solution will not yet be defined or supported by 
> the deployed servers):
> 
> - Send CRLF to SIP proxy for NAT binding keepalve
> 
> - Simultaneously send STUN binding requests to a separate
>   STUN server discovered in the domain of registered SIP
>   AOR, in order to detect NAT reboots
> 
> Yes it will add overhead (not good for an ultimate solution) but can 
> you point out any other profound flaw with this approach ? E.g. SIP 
> server and STUN server located in different address spaces so that the

> NAT reboot detection would possibly not work etc. ?
> 
> Regards,
> 
> Erkki

Say you have two SIP clients A and B that use the same default port
behind the same NAT and that NAT does port preservation (this is fairly
common).
Then the NAT reboots. Without loss of generality, assume A had got the
preserved port and B had not. Each UA has sends a stun packet that
create a new binding. If A sends first, it will get the same binding it
had last time and it will not detect that the NAT had rebooted. However,
it binding for SIP may or may not be the same as before the NAT rebooted
and it may not work. In this case, it seems like about 50% of the time,
one of two clients will think things are OK when in fact they are not.

--

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 22 Feb 2006 15:25:15 -0500

It can in some instances be exploited in a DOS attack if the front end
NAT is dumb enough to not recognize spoofing and maintains sticky
bindings. 

- Harry S Truman

-----Original Message-----
From: Gary Gan [mailto:[email-masked]] 
Sent: 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

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

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: "Michael Slavitch" <[email-masked]>
Date: Wed, 22 Feb 2006 15:35:52 -0500

Overloading CRLF, that is.

I do not know if there are any similar security considerations regarding
STUN.  

M

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

 
- Harry S Truman

-----Original Message-----
From: Gary Gan [mailto:[email-masked]]
Sent: February 22, 2006 2:25 PM
To: 'Dean Willis'; 'Cullen Jennings'
Cc: [email-masked]; 'Francois Audet'; 'Chris Boulton'; 'Michael Procter';

Gary Gan
Clique Communications

--

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: "Francois Audet" <[email-masked]>
Date: Wed, 22 Feb 2006 19:40:25 -0600

> Fourth, I'm starting to think that a PING request is a good 
> idea in general.  I've seen three good reasons why you would 
> want something like
> this: 1) to refresh NAT bindings, 2) as a heartbeat during a 
> session, and 3) as a check for the presence of a UA that is 
> independent of registrations.  This last bit could be very 
> useful, particularly for B2BUAs.  If I wanted to check 
> whether another UA is available, a quick PING would do 
> nicely.  I know all three of these things can be done with 
> OPTIONS but with these new semantics, a PING would make more 
> sense for reasons that have been discussed, load, security, etc.

Agree with 1. 

2 already exists: empty UPDATE as per RFC 4028.

Hadn't tought about 3 too much. I guess it would be a cheaper OPTIONS.

---

From: "Michael Slavitch" <[email-masked]>
Date: Thu, 23 Feb 2006 16:30:43 -0500

This is very real world.  Internal SIP server behind firewall,  SIP/PSTN
proxy  in the public internet or Enterprise registrar in the public
internet.  Most common implementation for highly distributed companies
that have no backbone, such as franchise operations. Common common real
world stuff.

Given that SIP proxies can be highly distributed and SIP is not
monolithic I can't see why this is freaky at all. In fact this has
massive benefits in areas such as security and redundancy.

This is to be expected in implementation.

Many businesses don't let you touch their NAT, and the proxy must be
behind the NAT router. 

Something like this shall address it.

M

 
 
- Harry S Truman

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: February 23, 2006 4:17 PM
To: Rohan Mahy
Cc: [email-masked]; 'Cullen Jennings'
Subject: Re: [Sip] Outbound and STUN Keep Alive

On Thursday 23 February 2006 10:40, Rohan Mahy wrote:
> 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.

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: "Michael Slavitch" <[email-masked]>
Date: Thu, 23 Feb 2006 16:48:57 -0500

For example:  

Company A has ~1000 outlets. Loose franchise business. Cookie cutter IT.
A real example, I'll leave the company unnamed.

Each franchise has a network, behind a NAT.  Each private network has an
identical private network address, let's call it 172.17.x.x.  This can
not change. It will not change. Period.

Each building is the same, each seat is the same, each server is the
same, POS, payroll, out of the box. Literally.
The infrastructure is quite literally packed in crates in a warehouse
with the furniture.

Common normal stuff in the "real world".  The real world isn't the
public internet. The real world is duplicate NAT.

Now, this company has a web based server under SSL for operations on the
public internet, this works fine for everything from procurement to
payroll to sales figures to supply chain.  

It also has one or more registration proxy on the public internet, and
has an agreement with one or more PSTN providers based on geographic
location.

But it also has to provide local wireline E911, local failover over
wireline, all that so it needs a local presence, not just hosted. It has
to survive different regulatory regimes in different countries: US,
Canada, Mexico, It has no centralized IT, because it is a loose
franchise model. Each franchise has to take local calls, and be in the
local yellow pages, that is their business.

No need for a VPN, no need for fiddling with firewalls or NAT, no need
for anything but drop, go and turn it on, even the individual
subscription identities are roles, not people. Build the building, move
in, turn it on, and it just works. Each identity is a local, not global
context.
 
In such a model, SIP works great if the proxy and UA each do STUN
Outbound and each do RTP NAT traversal.

Michael

 
- Harry S Truman

-----Original Message-----
From: Michael Slavitch [mailto:[email-masked]] 
Sent: February 23, 2006 4:31 PM
To: Dean Willis; Rohan Mahy
Cc: [email-masked]; Cullen Jennings
Subject: RE: [Sip] Outbound and STUN Keep Alive

M

 
 
- Harry S Truman

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: February 23, 2006 4:17 PM
To: Rohan Mahy
Cc: [email-masked]; 'Cullen Jennings'
Subject: Re: [Sip] Outbound and STUN Keep Alive

--
Dean

--

--