Subject: Re: [Sip] PING/PONG

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Dec 2004 22:57:25 -0500

inline.

Robert Sparks wrote:

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

My point is, there may not (indeed, won't be) a connection to that thing 
in the first place. It would need to be established only after the call 
setup is complete. How would the client know to do that? You also have a 
race condition, whereby even if the client knew to do this, a sip 
request could arrive from the voicemail server before the client can 
establish the connection. I'm just not seeing the benefit here.

-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: Robert Sparks <[email-masked]>
Date: Mon, 6 Dec 2004 08:51:35 -0600

I hope we're talking past each other at this point.

You seem to be proposing that I would _never_ open a connection with 
anything but
one proxy, even if I had network visibility to something else and the 
knowledge that
I wanted to talk to it.

I'm saying that if I want to have a dialog with something that I can 
reach (but it can't
open a connection to me), that I want to open a connection to it and 
for the duration
of that dialog, keep the connection alive. My original point is that I 
want to use the
same mechanism we define for keeping a connection to a proxy alive.

I think maybe you're only seeing the "tried to place a call and it 
ended up on some
random voicemail server" use case in your response below. Look at it 
from a
retrieving voicemail point of view. Then consider other services (like 
a presence server)
I might like to use, perhaps from a third party provider.

RjS

On Dec 3, 2004, at 9:57 PM, Jonathan Rosenberg wrote:

> inline.
>
> Robert Sparks wrote:
>
>>>
>>>> Endpoints behind the things we are wanting to do this refresh 
>>>> things to can be signaling
>>> 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
> My point is, there may not (indeed, won't be) a connection to that 
> thing in the first place. It would need to be established only after 
> the call setup is complete. How would the client know to do that? You 
> also have a race condition, whereby even if the client knew to do 
> this, a sip request could arrive from the voicemail server before the 
> client can establish the connection. I'm just not seeing the benefit 
> here.
>
> -Jonathan R.
>
>
> --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Dec 2004 00:59:55 -0500

> one proxy, even if I had network visibility to something else and the 

No; I'm saying that opening one up as a result of a record-route is not 
going to work.

> open a connection to me), that I want to open a connection to it and for 
> the duration

I think its fine to open a connection to something else, then send it a 
sip invite to create a sip dialog. What I think is a problem is opening 
one up to an element whose address I learn from a record-route after 
getting the 200 OK to my invite.

> 
> I think maybe you're only seeing the "tried to place a call and it ended 
> up on some
> random voicemail server" use case in your response below. Look at it from a
> retrieving voicemail point of view. Then consider other services (like a 
> presence server)

Those are ok, since it looks exactly like the normal persistent proxy 
connection case.

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Dec 2004 09:44:47 -0600

On Dec 6, 2004, at 11:59 PM, Jonathan Rosenberg wrote:

> No; I'm saying that opening one up as a result of a record-route is 
> not going to work.

Then we have been talking past each other. I wasn't suggesting you 
would.

>> of that dialog, keep the connection alive. My original point is that 
>> I want to use the
> I think its fine to open a connection to something else, then send it 
> a sip invite to create a sip dialog. What I think is a problem is 
> opening one up to an element whose address I learn from a record-route 
> after getting the 200 OK to my invite.
>
>> retrieving voicemail point of view. Then consider other services 
>> (like a presence server)