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

["Christian Stredicke" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Christian Jansson
> Sent: Thursday, November 11, 2004 4:32 AM
> To: Christian Stredicke; Spencer Dawkins
> Cc: [e-mail]
> Subject: RE: [Sip] PING/PONG [bcc][faked-from][heur]
> 
> 
> >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.

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

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

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

> 
> >- STUN (same as CRLF)
> 
> Just checking, STUN over TCP?

Why not?

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

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

> 
> / Christian Jansson
> 
>  
> 
> 
> _______________________________________________
> 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
> 
> 
> 

_______________________________________________
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