The current draft, draft-ietf-sip-outbound-00.txt, proposes to use STUN for UDP and CR/LF for TCP. However, the I believe the next version of the draft will recommend STUN for both UDP and TCP. At IETF 63, it was noted that the CR/LF mechanism will not work because it may take several minutes for the client to realize the TCP connection has failed.
cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 [EMAIL PROTECTED] ----- Original Message ----- From: "Paulo de Arruda Borelli" <[EMAIL PROTECTED]> To: "'Hyoungjoon Park'" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Tuesday, August 16, 2005 7:28 AM Subject: RE: [Sip-implementors] keep alive with NAT in SIP > Hi, Jun, > > Are you aware of any recommendation for SIP over UDP? > > -----Original Message----- > From: Hyoungjoon Park [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 16, 2005 7:11 AM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: RE: [Sip-implementors] keep alive with NAT in SIP > > Hi, Paulo, > > I think IETF has recommended the CR/LF mechanism for SIP over TCP, although > I'm quite not sure for NAT case. > Please check out the following link; > > http://www.softarmor.com/sipwg/meets/ietf61/notes/minutes-sip-ietf61.html > "1. TCP keepalive every periodic number of seconds? CRLF? > REGISTER? New message (PING)? > Comments: > - REGISTER is horrifically expensive - not a general solution > - CRLF doesn't generate an application ACK - have to wait for TCP > keepalives. question about if standard TCP interface allows check. We > think we can check unacked bytes in most(?) socket interfaces and use CRLF. > " > > Regards, > Jun > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paulo de > Arruda Borelli > Sent: Saturday, August 13, 2005 4:00 AM > To: [email protected] > Subject: RE: [Sip-implementors] keep alive with NAT in SIP > > Hi, Rakesh, > > You can use the expires value of the REGISTER messages. Just configure the > proxy to require a low expires value (like 60 seconds). This will force the > endpoint o re-register again every 60 seconds. In fact, in less than 60 > seconds - because, if they re-register exactly every 60 seconds, they will > certainly lose registration until the new registration gets active. Some > endpoints will re-register at 50% of expires (30 seconds, in this case); > some will at 90%. But they usually re-register at less than the nominal > expires value. > > The idea is that this will force the NAT pinhole to be open all the time - > enabling inbound flow (from the proxy to the endpoint) to reach the > endpoint. > > Some brands (of endpoints) also support the OPTIONS method as keep-alive > mechanism. This will also keep the NAT pinhole open. But the re-register > method is great - since it's usually supported. Notice it's imperative that > the proxy force expires to a low value. Usually, the endpoints send a > default value of 1800 or 3600 seconds - and not always configurable. To keep > the NAT pinhole open, it's imperative to re-register at less than one > minute. > > Paulo Borelli > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Nataraju A B > Sent: Friday, August 12, 2005 5:37 AM > To: 'Rakesh Dhandhukiya'; [email protected] > Subject: RE: [Sip-implementors] keep alive with NAT in SIP > > > > Regards, > Nataraju A.B. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rakesh > Dhandhukiya > Sent: Tuesday, August 09, 2005 1:03 PM > To: [email protected] > Subject: [Sip-implementors] keep alive with NAT in SIP > > Hi ! > > I want to keep alive with NAT. First of how to know the keep alive timeout > of NAT for UDP. Is there any file like tcp timeout ? > Is ICE used for NAT keep alive? > > [ABN] service provider may not disclose these timer values... only way to > find out these timer values would be to use trail and error method.... > I don't think ICE been used to NAT keep alive... > > Thanks. > > Rakesh Dhandhukiya > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
