2011/10/19 Benny Prijono <bennylp at teluu.com>: > 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. Oh no, I will not say that since sending CRLF is valid AFAIK ;) But it has a drawback: it just involves client-to-server traffic. AFAIK some NAT routers could close the NAT mapping if they don't receive server-to-client traffic for a while (I've never seen them however). >>> 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. Thanks, understood. >>> 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! ?:) Ahh ok ok, I didn't understand that. Since you said that pjnath does not depend on pjsip library I understood that it open a different UDP socket. My fault. But then I don't understand what you meant with: "That means our SIP transport must be able to multiplex STUN traffic, which means to bring pjnath dependency into pjsip library." I you can send STUN requests from the same source SIP UDP port, then why cannot you send STUN Binding Requests for NAT keealive? The STUN response will be received in the same SIP UDP port in which PISIP listens so the SIP UDP parser must already be ready to process an incoming STUN response. What is the problem then? (sorry if I missunderstood something). Thanks a lot for your responses. -- I?aki Baz Castillo <ibc at aliax.net>
