Subject: RE: [Sip] PING/PONG [bcc][faked-from][heur]

From: "Christian Jansson" <[email-masked]>
Date: Tue, 9 Nov 2004 17:25:51 +0100

>>[Chris Boulton] Whatever we decide we shouldn't restrict it to 'one-way'.  In different deployments and scenarios it should be possible for either >>entity to keep a connection alive. 
> 
>(CS) Sure. But the role has to be negotiated. If possible, the UA should do that job. If it is not able to do this (e.g. because it does not support >refreshing) the fall back solution will always be that the network side has to do the job. 
 
Does it really have to be negotiated? If we all think that refreshes should be handled by the UA, why not decide that that is the only standardized way to do it. Given that things have worked without this negotiation for quite some time now, things will not get any worse just because we write down a standardized way for a UA to do keep-alives. If some UAs did not take the keep-alive issue in consideration before this discussion begun, it could only mean two things:
1) The UA did not work in the real world, and I guess they would have noticed that. 
2) They used STUN/CRLF, invented something else, or perhaps they sent OPTIONS/PING/??? from the server, which they can continue to do even though it is not the documented way of doing it. Either they update their UA according to "standard" keep-alives or they keep the proprietary solution, and I don't think the standard for keep-alives should try to compensate for all those solutions. 

/ Christian Jansson

_______________________________________________
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: "Christian Stredicke" <[email-masked]>
Date: Tue, 9 Nov 2004 22:06:12 +0100

Well, the negotiation who refreshes is more or less the question if you have a legacy device or not.

I totally agree, if there is no legacy device, the UA should refresh.

But currently, there are only legacy devices or proprietary implementations.-) Lets agree on a standard, that's why were are here.

My proposal: A new header "Keep-Alive" in the REGISTER request:

(A) Propose refresh every 15 seconds, offer methods stun, register, crlf

REGISTER sip:snom.com SIP/2.0
Via: SIP/2.0/UDP 10.67.87.210:4064;branch=z9hG4bK-g1gkta5je1yq;rport
From: "Christian Stredicke" <sip:[email-masked]>;tag=l3rj6dvhfl
To: "Christian Stredicke" <sip:[email-masked]>
Call-ID: e52d914160a1-8yd3fpzu59l7@snom220
CSeq: 1 REGISTER
Max-Forwards: 70
Contact: <sip:[email-masked]:4064;line=o58ete25>;q=1.0
Keep-Alive: 15;method="stun,crlf,register"
Expires: 3600
Content-Length: 0

(B) Other party acknowledges and selects stun refreshes:

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 10.67.87.210:4064;branch=z9hG4bK-hypaxu2640zy;rport=4064;received=130.129.97.54
From: "Christian Stredicke" <sip:[email-masked]>;tag=l3rj6dvhfl
To: "Christian Stredicke" <sip:[email-masked]>;tag=0zikcb2fzo
Call-ID: e52d914160a1-8yd3fpzu59l7@snom220
CSeq: 1 REGISTER
Contact: <sip:[email-masked]:4064;line=o58ete25>;expires=3600
Keep-Alive: 15;method="stun"
Content-Length: 0

CS 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christian Jansson
> Sent: Tuesday, November 09, 2004 12:01 PM
> To: Christian Stredicke; Chris Boulton; Christer Holmberg 
> (JO/LMF); [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip] PING/PONG [bcc][faked-from][heur]
> 
> 
> 
> >>[Chris Boulton] Whatever we decide we shouldn't restrict it to 
> >>'one-way'.  In different deployments and scenarios it 
> should be possible for either >>entity to keep a connection alive.
> > 
> >(CS) Sure. But the role has to be negotiated. If possible, 
> the UA should do that job. If it is not able to do this (e.g. 
> because it does not support >refreshing) the fall back 
> solution will always be that the network side has to do the job. 
>  
> Does it really have to be negotiated? If we all think that 
> refreshes should be handled by the UA, why not decide that 
> that is the only standardized way to do it. Given that things 
> have worked without this negotiation for quite some time now, 
> things will not get any worse just because we write down a 
> standardized way for a UA to do keep-alives. If some UAs did 
> not take the keep-alive issue in consideration before this 
> discussion begun, it could only mean two things:
> 2) They used STUN/CRLF, invented something else, or perhaps 
> they sent OPTIONS/PING/??? from the server, which they can 
> continue to do even though it is not the documented way of 
> doing it. Either they update their UA according to "standard" 
> keep-alives or they keep the proprietary solution, and I 
> don't think the standard for keep-alives should try to 
> compensate for all those solutions. 
> 
> / Christian Jansson
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Christian Jansson" <[email-masked]>
Date: Thu, 11 Nov 2004 09:59:11 +0100

>Lets have a way to indicate these options and let the SBC decide what
>method it likes/supports.

So, this discussion is about how to make UAs interop with SBCs? That was
new to me. As SBC are not even well defined does it make sense to try to
make UAs interop with them? Don't get me wrong, I do think it is very
good to get a standardized way of handling the keep-alive problem, but
putting a SBC as the focus of the requirements before it is well defined
seems strange.

>You just mentioned another way of keeping TCP connections alive. Thats
>good! 
> So far we have:

>- CRLF (frequenly used today, but not indicated by user agent)

My gut feeling was that could be done without any
indication/negotiation, but now I understand why you want this feature,
you have a SBC in mind. If that had been written somewhere in this
thread, at least I would have understood your motivation.

>- STUN (same as CRLF)

Just checking, STUN over TCP?

>- PING/PONG or whatever (tbd, maybe superflous)
>- OPTIONS (big overhead, but compatible)
>- REGISTER (same as OPTIONS, but even bigger overhead)
>- TCP low-level (how can this be addressed by the application?)
>- No refreshing ("legacy device")

REGISTER without a contact header, would that make it light enough? Bad
to overload REGISTER? Backwards compatible? Perhaps the response would
still need to include all registered contacts for the AOR, so the
registrar still has to access the DB.

My opinion is that none of the OPTIONS, REGISTER, TCP low-level
fiddling, no refreshing at all, is the right method for solving the
problem, exactly because of the problems you stated with each method.

/ Christian Jansson

---

From: "Christian Stredicke" <[email-masked]>
Date: Thu, 11 Nov 2004 11:47:52 +0100

> Sent: Thursday, November 11, 2004 4:32 AM
> To: Christian Stredicke; Spencer Dawkins
> Cc: [email-masked]

Lets say a SBC is an example. I dont want to be pulled into the SBC
discussion.

> thread, at least I would have understood your motivation.

Well the [refreshing device] needs to know if it has to do something or
not (eg. send OPTIONS periodically). This needs to be indicated. Looking
at the User-Agent header is surely not a good way...

> Just checking, STUN over TCP?

Why not?

> problem, exactly because of the problems you stated with each method.

STUN sounds like a very good method to me...