RE: [Sip] PING/PONG

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