RE: [BEHAVE] running two application on same port

> For STUN client to determine the NAT type we may have to run 
> it on the port over which the needy application is already running.

RFC3489 recommended determining the NAT type.  However, in practice,
this has been found to not work well because some NATs change their
behavior after a several round-trips of UDP messages (becoming full 
cone, for example), and others change their behavior to "symmetric"
if multiple hosts behind the NAT use the same source UDP port.  

Because of this, it is now considered 'state of the art' to _not_
probe to determine the kind of NAT you're behind.

>   How can we achieve this functionality as now we have to run 
> stun client using the same port  and same protocol as our 
> application is using?

You have to multiplex STUN with your application protocol.  Some
application protocols, such as RTP (RFC3550) are easily multiplexed
with STUN because the first few bits of a STUN packet and of an
RTP packet are different.  DTLS happens to demultiplex well, too
(see table in 
http://tools.ietf.org/html/draft-mcgrew-tls-srtp-00#section-3.6.2).

If your application protocol doesn't demultiplex as easily, you
may find it useful to rely on STUN's MAGIC-COOKIE attribute and
FINGERPRINT attributes to demultiplex STUN and your application 
protocol.  You could, of course, prefix all of your 
application protocol messages with an 8-bit value that 
doesn't overlap with STUN's first 8 bits, but that shouldn't be
necessary considering STUN's MAGIC-COOKIE and FINGERPRINT 
attributes, which were designed to make it possible to 
demultiplex STUN with arbitrary application protocols.

-d

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave