[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] PING/PONG
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
On Nov 18, 2004, at 5:14 AM, 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 at cisco.com]
Sent: 18 November 2004 04:46
To: Steve Langstaff
Cc: Christian Stredicke; sip at 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 at ietf.org [mailto:sip-bounces at ietf.org]On Behalf Of
Jonathan Rosenberg
Sent: 17 November 2004 16:40
To: Christian Stredicke
Cc: sip at 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 at 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 at cs.columbia.edu for questions on current sip
Use sipping at 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 at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip