Re-sending the query...... If any of you could clarify this, it would be great. Thanks, Prakash.
-----Forwarded Message----- From: Ulrich Prakash <[EMAIL PROTECTED]> To: Jonathan Rosenberg <[EMAIL PROTECTED]> Cc: sip-impl <[email protected]> Subject: Re: [Sip-implementors] keep alive with NAT in SIP Date: 16 Sep 2005 12:50:30 +0530 Hi, I need a small clarification in this response. Please view it inline tagged as [Prakash]... On Tue, 2005-08-16 at 20:14, Jonathan Rosenberg wrote: > Please see: > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-00.txt > > which discusses NAT traversal for SIP signaling. Bindings for UDP are > kept alive by sending STUN packets to the SIP port of the SIP server. > The document talks about CRLF for TCP, but per IETF 63 this will also > change to STUN over TCP. [Prakash]=>Inorder to keep the SIP port alive(5060), we can send STUN requests periodically with source port as 5060. My question is: Is it enough if we send this STUN refresh request to STUN server? or must we send this to SIP Proxy server, to keep the binding alive? If the STUN request needs to be sent to the SIP Proxy server only, and not to STUN server, then why it is so? > > Keeping NAT bindings alive for media traffic is covered in ICE: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-05.txt [Prakash]=> Inorder to keep the RTP port alive( say 8000), we can send STUN requests periodically with source port as 8000. My question is: Is it enough if we send this STUN refresh request to STUN server? or must we send this to SIP UA endpoint(in the public network), to keep the binding alive? If the STUN request needs to be sent to the SIP UA endpoint only, and not to STUN server, then why it is so? If the STUN request needs to be sent to the SIP UA enpoint only, why it is so? Inother words, must the SIP UA endpoint in the public network, support STUN server? Please let me know your views on this. Thanks, Prakash. > > The approach there uses STUN sent to the RTP ports when the peer > supports ICE, otherwise recommends RTP no-op: > > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-no-op-00.txt > > -Jonathan R. > > Paulo de Arruda Borelli wrote: > > > 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.htm > l > > "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 > > Disclaimer: This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers, privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. _______________________________________________ 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
