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

From: "Chris Boulton" <[email-masked]>
Date: Tue, 14 Feb 2006 10:29:43 -0000

If Cullen is right

[Chris Boulton]Dean - what do you mean if :-). 

 and the STUN work takes 1/10th of OPTIONS (or less), 
then we'd clearly have an advantage in favor of STUN. 

[Chris Boulton] I also feel that anything that helps promote the use and
deployment of STUN in out networks is a good thing and should be
encouraged.  IMHO it fits and is far more elegant than the other
solutions + has all the benefits previously mentioned.  Why hack SIP?
Why double CRLF when we have a suitably sensible probing protocol. 

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: Hisham Khartabil <[email-masked]>
Date: Tue, 14 Feb 2006 13:53:39 +0100

> solutions + has all the benefits previously mentioned.  Why hack SIP?

Because it is not a good design to have 2 protocols run on the same 
port. You will have to hack your SIP parser to distinguish between SIP 
and STUN messages. You will also need to create a horizontal link 
between your SIP stack and STUN module.

Hisham

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

---

From: Thomas Leseney <[email-masked]>
Date: Tue, 14 Feb 2006 14:07:15 +0100

Dear Hisham,

STUN usually run on port 3478.
http://www.iana.org/assignments/port-numbers

Regards,

Thomas

Hisham Khartabil wrote:

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

---

From: Thomas Froment <[email-masked]>
Date: Tue, 14 Feb 2006 14:25:02 +0100

Thomas Leseney wrote:

>> port. You will have to hack your SIP parser to distinguish between 
>> SIP and STUN messages. You will also need to create a horizontal link 
In order to support  double CR/LF, you will also have to hack your SIP 
stack, otherwise it will, for sure, raise some kind of parse exception 
;-)...

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 14 Feb 2006 14:38:17 +0100

> STUN usually run on port 3478.

Not in this case :) You are using stun to keep sip port bindings open.

Hisham

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

---

From: [email-masked]
Date: Tue, 14 Feb 2006 19:20:37 +0530

assume that the stun server is the next hop after the NAT to support the symmetric NAT.

UA - > NAT -> STUN SERVER -> PROXY.

Now, if a SIP message arrives then the STUN Server has to distinguish between a STUN or a SIP request and then has to send the sip message to the Proxy. i.e. do we also want STUN to act as a proxy for sip requests? Any message from UA will traverse thru NAT and then STUN and then Proxy ( if sip message). Ortherwise, as hisham has pointed we need to have to hack your SIP parser to distinguish between SIP and STUN messages. Both, the sip message and Proxy stack has to be listening on the same port.

Regards,

--Vikram.

Hisham Khartabil <[email-masked]>

Hisham Khartabil <[email-masked]>

Sent by: [email-masked]

02/14/2006 07:08 PM

To

Thomas Leseney <[email-masked]>

cc

"[email-masked] List" <[email-masked]>

Subject

Re: [Sip] Outbound and STUN Keep Alive

Hisham

>>> [Chris Boulton] I also feel that anything that helps promote the use

>>> and

*********************** FSS-Unclassified ***********************

---

From: Thomas Froment <[email-masked]>
Date: Tue, 14 Feb 2006 15:02:27 +0100

[email-masked] wrote:

> Now, if a SIP message arrives then the STUN Server has to distinguish 
> between a STUN or a SIP request and then has to send the sip message 
> to the Proxy. i.e. do we also want STUN to act as a proxy for sip 
> requests? Any message from UA will traverse thru NAT and then STUN and 
> then Proxy ( if sip message).
>
This is not the question here... Of course, a STUN server does not act 
as a SIP proxy, this is just a redirection switch problem:
do we prefer:
if (STUN_PAYLOAD) then
 handleStunMessage(Message)
else
handleSIPMessage(Message)

OR
if (double CR/LF) then
 handlePingMessage(Message)
else
handleSIPMessage(Message)

This is quite the same thing,
the only question is, does double CR/LF  work (Cullen's question) ? 
seems yes
OR is it better to make STUN, because it is more consistent with UDP case ?

I would prefer to make STUN, since it will actually be more consistent 
to have the same kind of procedure for UDP and TCP,
but if CR/LF works, I don't have any objection...

> Ortherwise, as hisham has pointed we need to have to hack your SIP 
> parser to distinguish between SIP and STUN messages. Both, the sip 
> message and Proxy stack has to be listening on the same port.
>
> Regards,
> --Vikram.
>
> Inactive hide details for Hisham Khartabil 
> <[email-masked]>Hisham Khartabil <[email-masked]>
>
>
>                         *Hisham Khartabil <[email-masked]>*
>------------------------------------------------------------------------
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Feb 2006 09:09:02 -0500

The model that is described in sip-outbound is that the proxy listens on 
port 5060 for messages. Messages can arrive formatted either as SIP, or 
as STUN. It is essential for the nat traversal properties that the 
keepalives be sent to the same port as the SIP signaling; without that, 
you will not get traversal through symmetric NAT or similar firewalls.

This does in fact mean that your parser needs to be modified so that it 
first detects whether the message is sip or stun, and then sends it to 
the right code module appropriately. This is easily doable, and not that 
complicated. It is not beautiful, but engineering is about making 
tradeoffs. Here, the ENORMOUS cost of SIP message processing relative to 
stun, combined with the frequency of the keepalives, argues in favor of 
this tradeoff.

I will further note that a "modified PING message", or any other kind of 
SIP message processing that does not follow SIP semantics as defined in 
RFC 3261, is effectively identical to the multiple-protocol mechanism of 
running STUN and SIP on the same port. You'll need to figure out which 
protocol it is (SIP or modified SIP), and send the request to the right 
code path appropirately.

Another thing to note on disambiguation. A fairly major revision of stun 
is coming which is going to make it much clearer about how it is 
applicable to these types of problems. One of the changes that will be 
in the draft is the usage of a "magic cookie", similar to the via branch 
cookie, that occupies some of the bits in the STUN transaction ID. This 
means that there is a well known sequence of characters in a fixed 
position in every single stun message. This makes it trivial to 
differentiate stun from anything else.

Thanks,
Jonathan R.

[email-masked] wrote:

> between a STUN or a SIP request and then has to send the sip message to 
> the Proxy. i.e. do we also want STUN to act as a proxy for sip requests? 
> Any message from UA will traverse thru NAT and then STUN and then Proxy 
> ( if sip message). Ortherwise, as hisham has pointed we need to have to 
> hack your SIP parser to distinguish between SIP and STUN messages. Both, 
> the sip message and Proxy stack has to be listening on the same port.
> 
> Regards,
> --Vikram.
> 

-- 
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: "Frank W. Miller" <[email-masked]>
Date: Tue, 14 Feb 2006 10:01:53 -0500

Why would we use STUN to keep SIP port bindings alive?  What are we
going to do when the next protocol that communicates ports other than
the ones it uses comes along, do multiplexing of multiple ports after
the demultiplexing of each has occurred?

IMHO, STUN should be used to discover NATs and thats it.  It should be
the responsibility of the protocols using the ports to make sure their
ports stay alive at the NAT.

I thought double CRLF was a hack.  Merging two protocols onto the same
port is a hack worthy of a ring of hell.  The problem here is keeping
the SIP port open, and thats a SIP problem, not a STUN problem.

While I'm sympathetic to Dean's and Cullen's comments about performance,
I just can't buy it (besides, the hardware vendors will luv it since the
will get to sell bigger iron).  We can limit the use of these things so
that these performance issues are minimized.  I guess my bottom line is
that this seems to be a SIP problem and a proper design approach would
be to solve it in SIP.

FM

---

From: Thomas Froment <[email-masked]>
Date: Tue, 14 Feb 2006 16:25:03 +0100

>that this seems to be a SIP problem and a proper design approach would
The point I would like to notice is that accepting STUN requests on the 
same port as SIP is already common practice for many implementations
willing to support NAT traversal...
The problem this draft is addressing is a NAT traversal problem (more 
than a "SIP problem"), so, reusing what is already existing to pass NATS
seems fair..
Following your points, double CR/LF and STUN are "hacks", so you would 
prefer to solve a SIP problem with SIP: that means, for instance,
using OPTION request. Seems fine, but that's really a concern because 
OPTION would have a *much* more bigger impact on performances, since it 
mandates to parse completely a message, it creates a  SIP Message in 
memory and a SIP transaction... From the implementation point of view, 
this is  in fact very common to make a "protocol switch" looking at few 
bytes of a received message:
as an illustration, when handling SIP compressed messages with SIGCOMP, 
we are just looking at the SIGCOMP prefix at the beginning of the
message to decide if we should try to decompress it...