Re: [Sip] PING/PONG

[Robert Sparks <[e-mail]>]

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

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

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

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.

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

Agreed.
>
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [e-mail]                              FAX:   [phone]
> http://www.jdrosen.net                         PHONE: [phone]
> 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip