Subject: RE: [Sip] PING/PONG

From: "Steve Langstaff" <[email-masked]>
Date: Thu, 18 Nov 2004 11:14:42 -0000

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:[email-masked]]
Sent: 18 November 2004 04:46
To: Steve Langstaff
Cc: Christian Stredicke; [email-masked]
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: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: 17 November 2004 16:40
> To: Christian Stredicke
> Cc: [email-masked]
> 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
[email-masked]                              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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Charles Eckel <[email-masked]>
Date: Fri, 19 Nov 2004 08:59:15 -0800

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:

> 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.
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Nov 2004 02:05:34 -0500

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:

>> Sorry, I didn't realise the scope of this discussion was 
>> client-to-proxy - that's where my confusion lay.
>>
>> 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.
>>
>>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 23 Nov 2004 15:24:36 -0600

This conversation just got too loose with its terminology for me.

3261 proxies have a UAS core.

Endpoints behind the things we are wanting to do this refresh things to 
can be signaling
directly with endpoints that aren't (a service provider could let 
people talk to voice-mail
or conference servers directly).

While the long-lived client-to-service-provider-proxy connection is a 
good example
to use for motivation, I would prefer that we ensure we build something 
that works
in general.

The DNS solution would work for those the services I call out above.  
I'm not yet sure
if its the right way to go.

I can see a use for being able to signal (or at least detect) support 
for this kind of keep-alive
between ephemeral endpoints too.

RjS

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Nov 2004 02:54:53 -0500

> 3261 proxies have a UAS core.

I don't think so; the term for that is "proxy core" and is quite 
distinct from the UAS and UAC cores. Note the definition of TU:

  Transaction User (TU): The layer of protocol processing that
          resides above the transaction layer.  Transaction users include
          the UAC core, UAS core, and proxy core.

3261 proxies have a server transaction (per figure 4) but thats not the 
same thing.

> directly with endpoints that aren't (a service provider could let people 
> talk to voice-mail

I don't see how that practically works in the presence of nat. If you 
are using tcp/tls, the thing to which you have a connection open is the 
only place from which you can get subsequent requests. Thus, if I make a 
call that lands on a voicemail server, the proxy holding my tcp/tls 
connection has to be on the signaling path, or it just won't work.

> to use for motivation, I would prefer that we ensure we build something 

I disagree here. The original connect-reuse draft tried to address both 
the client-to-proxy and proxy-to-proxy problems and ended up doing 
neither well. We found we needed to split it because these were 
sufficiently different problems. It seems like you are suggsting that 
they are not, and that we need a single mechanism for both?

> if its the right way to go.

The other alternative I suppose is to use a URI parameter ala 
draft-ietf-sip-compression. Something like keepalive=stun. Thus, a 
preloaded route header for a proxy that supports it would look like:

sip:outbound.proxy.com;keepalive=stun

This is arguably superior for exactly the same reasons we shied away 
from putting sigcomp into dns - you get this combinatorial explosion of 
records, since sigcomp and stun as well could both be used in any transport.

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 24 Nov 2004 08:37:21 -0600

On Nov 24, 2004, at 1:54 AM, Jonathan Rosenberg wrote:

> 3261 proxies have a server transaction (per figure 4) but thats not 
> the same thing.

Fair enough - I was thinking of the role-switch proxies take on error 
responses, but
I'll withdraw the complaint.

>
>
>
>> Endpoints behind the things we are wanting to do this refresh things 
>> to can be signaling
> are using tcp/tls, the thing to which you have a connection open is 
> the only place from which you can get subsequent requests. Thus, if I 
> make a call that lands on a voicemail server, the proxy holding my 
> tcp/tls connection has to be on the signaling path, or it just won't 
> work.

If I can establish a tcp/tls connection to that voicemail server, then 
subsequent requests from it can
come back down that connection assuming we can keep it alive.

>> to use for motivation, I would prefer that we ensure we build 
>> something that works
>> in general.
>
> I disagree here. The original connect-reuse draft tried to address 
> both the client-to-proxy and proxy-to-proxy problems and ended up 
> doing neither well. We found we needed to split it because these were 
No, I'm not trying to push this back to arbitrary node to arbitrary 
node. I am trying to push it closer to UAC to arbitrary node.
And I'm only talking about keeping the connection alive, which is a 
different problem than figuring out what SIP thing is
on each end so you can affect routing choices (which is a big part of 
what's been making connection-reuse hard).
> from putting sigcomp into dns - you get this combinatorial explosion 
> of records, since sigcomp and stun as well could both be used in any 
> transport.

Agreed.