On Wed, Oct 19, 2011 at 8:33 PM, I?aki Baz Castillo <ibc at aliax.net> wrote: > Right, but that is the way in which RFC 5626 states that a SIP UDP > client MUST mantain the keep-alive. How does PJSIP mantain the NAT > keep-alive when using UDP? > By default, CRLF. You can put more inventive packet if you want (including STUN2 packet actually). And please spare the next comment about sending CRLF with UDP being non-standard and such, everybody knows this and everybody implements this anyway. > >> For now we only need outbound for its NAT traversal capability, not >> for its reliability feature (i.e. the multiple flows thing). > > So then what does it mean the announcement of RFC 5626 support in PJSIP? :) > Actually we *do* support multiple flows. But the primary motivation for outbound was because our trick for TCP behind NAT (and TLS) is not reliable, not because we need multiple links for added reliability (although we provide that anyway). That's what I meant with my previous comment. > >> So in this case the existing UDP + STUN works just fine. > > The STUN test (RFC 3489) has been deprecated in the new STUN RFC 5389 > since it does not work in many cases (some routers change the NAT type > dynamically, it's documented in RFC 5389). This means that STUN can > only be used for knowing our public IP:port when we use the *same* > source port as the used for sending the STUN Binding Request. > I know that. We don't rely on NAT type detection, that's for sure. We do that only for debugging aid, and it's fun to know what's the type of the router in front of you is. And of course we use the same port for SIP as the one where we sent STUN from. C'mon, (unless I misunderstood what you mean) this is basic stuff! :) > >>> PS: I've a SIP proxy implementing Outbound for SIP UDP/TCP/TLS >>> clients. Ask me if you want to test. >>> >> >> Have you tested with TCP yet? > > Yes. And it works with CSipSimple and Blink (both using PJSIP). > Okay, thanks. Benny
