Re: [Sip] PING/PONG
Jonathan Rosenberg <jdrosen@cisco.com> Mon, 22 November 2004 07:18 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23942 for <sip-web-archive@ietf.org>; Mon, 22 Nov 2004 02:18:44 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW8We-0006Mg-3u for sip-web-archive@ietf.org; Mon, 22 Nov 2004 02:22:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW8M9-0003LT-5P; Mon, 22 Nov 2004 02:11:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW8HD-0001Hm-57 for sip@megatron.ietf.org; Mon, 22 Nov 2004 02:06:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13922 for <sip@ietf.org>; Mon, 22 Nov 2004 02:06:18 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW8Kb-0006AV-N6 for sip@ietf.org; Mon, 22 Nov 2004 02:09:50 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2004 23:08:43 -0800
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAM75Ww0023086; Sun, 21 Nov 2004 23:05:33 -0800 (PST)
Received: from [10.0.0.125] (sjc-vpn2-471.cisco.com [10.21.113.215]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFW79660; Sun, 21 Nov 2004 23:05:35 -0800 (PST)
Message-ID: <41A18FBE.2060707@cisco.com>
Date: Mon, 22 Nov 2004 02:05:34 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Charles Eckel <eckelcu@cisco.com>
Subject: Re: [Sip] PING/PONG
References: <CD9775120D600F43B9C50329395E9DB64F321F@ivor.citel.com> <419E2663.6000409@cisco.com>
In-Reply-To: <419E2663.6000409@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, Christian Stredicke <Christian.Stredicke@snom.de>, Steve Langstaff <steve.langstaff@citel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Content-Transfer-Encoding: 7bit
I think there may be some confusion here about how this works. The STUN server is a logical function that *must* run on the same IP and port as the SIP server. In other words, if I have a proxy, and it is listening for SIP messages on 1.2.3.4:5060, then it would also be able to process STUN requests on 1.2.3.4:5060. A response to a stun request sent to that IP/port would get sent from that same port. Thus, there is no separate stun server here. The stun functionality is co-resident with the sip proxy; this is necessary to make sure that the proxy knows that the client is still there, to allow the client to know that the proxy is still there, and lastly, to ensure that the keepalives refresh the nat bindings in a way that allow the client to continue to reach the SIP proxy server and vice-a-versa. Since the keepalives are sent to the same place where the signaling traffic goes/comes from, the keepalives work even with symmetric nat. -Jonathan R. Charles Eckel wrote: > The problem is that if you leave it entirely at the STUN level you are > just ensuring that STUN server will be able to reach the STUN clients > all times. However, what you really need is for the SIP proxy to be able > to reach its SIP clients at all times. If the STUN server and proxy > server are both listening and sending from the same port, you are fine > using STUN by itself; otherwise, you need to do something else. > > Cheers, > Charles > > Steve Langstaff wrote: > >> Sorry, I didn't realise the scope of this discussion was >> client-to-proxy - that's where my confusion lay. >> >> A further question from my (simplistic) viewpoint... If this issue >> is/could be generic to all STUNned traffic (not just sip+stun), would >> it not be better to push the problem down into the STUN 'layer' and >> let the STUN client and server sort out keeping the NAT bindings >> alive? I'm guessing that the SIP client already 'knows' it has to use >> STUN to reach the proxy, and so could ask it's STUN client to keep the >> binding(s) alive as appropriate. >> >> >> -- >> Steve Langstaff. >> >> >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 18 November 2004 04:46 >> To: Steve Langstaff >> Cc: Christian Stredicke; sip@ietf.org >> Subject: Re: [Sip] PING/PONG >> >> >> There isn't a UAS involved here; these requests go from the client (UAC) >> to its proxy. >> >> How the proxy indicates to the UAC that it is capable of processing >> these keepalives is a good question. My first thought is that this would >> be something in DNS; a new service in the NAPTR record for indicating >> the sip+stun combination. >> >> -Jonathan R. >> >> Steve Langstaff wrote: >> >> > Should point 2 read "The user agent server indicates if it can >> respond to client refresh requests"? >> > >> > -- >> > Steve Langstaff. >> > >> > >> > -----Original Message----- >> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >> > Jonathan Rosenberg >> > Sent: 17 November 2004 16:40 >> > To: Christian Stredicke >> > Cc: sip@ietf.org >> > Subject: Re: [Sip] PING/PONG >> > >> > >> > >> > >> > Christian Stredicke wrote: >> > >> > >> >>So my understanding is: >> >> >> >>1. We should use *only* STUN for refreshing bindings (either UDP or >> TCP, >> >>what about TLS) >> > >> > >> > Yes, TLS too. TLS runs ontop of TCP after all. >> > >> > >> >>2. The user agent indicates if it can do it (no negotiation on >> >>capabilities) >> >> >> >>3. Refreshing must be done from the client >> >> >> >>Can we agree on that? >> > >> > >> > Yes. >> > >> > Server originating refreshing is in the wrong direction. It is the >> > client utilizing the service; if it wishes to make use of that >> service, >> > it has to be responsible for refreshing the connection. >> > >> > -Jonathan R. >> > >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Christer Holmberg (JO/LMF)
- RE: [Sip] PING/PONG Steve Langstaff
- Re: [Sip] PING/PONG Bob Penfield
- RE: [Sip] PING/PONG Christer Holmberg (JO/LMF)
- RE: [Sip] PING/PONG Christian Stredicke
- Re: [Sip] PING/PONG Bob Penfield
- RE: [Sip] PING/PONG Chris Boulton
- RE: [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Steve Langstaff
- RE: [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Chris Boulton
- RE: [Sip] PING/PONG Steve Langstaff
- Re: [Sip] PING/PONG Spencer Dawkins
- RE: [Sip] PING/PONG Christian Stredicke
- Re: [Sip] PING/PONG Klaus Darilion
- Re: [Sip] PING/PONG Jonathan Rosenberg
- [Sip] How to get old messages on archives!! vikram bhuskute
- RE: [Sip] PING/PONG Christian Stredicke
- Re: [Sip] PING/PONG Jonathan Rosenberg
- RE: [Sip] PING/PONG Steve Langstaff
- RE: [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Steve Langstaff
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Charles Eckel
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks