[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] PING/PONG
Robert Sparks wrote:
This conversation just got too loose with its terminology for me.
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.
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).
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.
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.
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?
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.
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.
--
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