Re: [Sip] PING/PONG

Charles Eckel <eckelcu@cisco.com> Fri, 19 November 2004 17:20 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 MAA22930 for <sip-web-archive@ietf.org>; Fri, 19 Nov 2004 12:20:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVCTt-0001QH-HY for sip-web-archive@ietf.org; Fri, 19 Nov 2004 12:23:47 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVCDs-0001of-P1; Fri, 19 Nov 2004 12:07:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVC6y-0007zS-WA for sip@megatron.ietf.org; Fri, 19 Nov 2004 11:59:53 -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 LAA21066 for <sip@ietf.org>; Fri, 19 Nov 2004 11:59:50 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVC9q-0000u0-GV for sip@ietf.org; Fri, 19 Nov 2004 12:02:50 -0500
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2004 08:59:41 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAJGx8W9029328; Fri, 19 Nov 2004 08:59:17 -0800 (PST)
Received: from [128.107.171.115] ([128.107.171.115]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Nov 2004 08:59:16 -0800
Message-ID: <419E2663.6000409@cisco.com>
Date: Fri, 19 Nov 2004 08:59:15 -0800
From: Charles Eckel <eckelcu@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Langstaff <steve.langstaff@citel.com>
Subject: Re: [Sip] PING/PONG
References: <CD9775120D600F43B9C50329395E9DB64F321F@ivor.citel.com>
In-Reply-To: <CD9775120D600F43B9C50329395E9DB64F321F@ivor.citel.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Nov 2004 16:59:16.0346 (UTC) FILETIME=[1A6515A0:01C4CE59]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, Christian Stredicke <Christian.Stredicke@snom.de>
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: 36c793b20164cfe75332aa66ddb21196
Content-Transfer-Encoding: 7bit

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
> 

_______________________________________________
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