Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 21 Jun 2006 18:57:44 +0200

Hi,

There must also be a way for the edge proxy to indicate to the client that it supports the STUN keep-alive usage. Because, if the other outbound features aren't supported/requested, there will be no "outbound" in the Supported header of the registration response.

Regards,

Christer

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: 21. kesäkuuta 2006 3:33
To: Jonathan Rosenberg; Christer Holmberg (JO/LMF); Cullen Jennings
Cc: [email-masked]
Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis

I agree.

It would be nice if in Outbound, there was some sort of indication on what is required to be there if only the keepalive is done.

Maybe a little paragraph on this in the section on keep-alive in
sip-outbound-04
would help. I think it would really help to have some guidance on this to answer the question that Christer has.

(Besides the use that Jonathan points to, it could be useful in certain environments to phase out PINGs, short-lived registration, CRLFs and other legacy mechanisms. I can see an option on a phone to use STUN-in-SIP for

keep-alive as implementable today).

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2006 16:51
> To: Christer Holmberg (JO/LMF)
> Cc: [email-masked]
> Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis
> 
> 
> I think we should allow the STUN keepalives without the rest of the 
> stuff. Its a handy tool for inter-server keepalives in cases where 
> there are no NAT or firewalls.
> 
> -Jonathan R.
> 
> Christer Holmberg (JO/LMF) wrote:
> 
> > 
> > Hi,
> > 
> > A few issues on the outbound draft:
> > 
> > Q1:
> > -----
> > 
> > The outbound draft currently defines the usage of STUN for NAT 
> > keep-alive.
> > 
> > However, since NAT keep-alive has been added as a STUN usage to the 
> > STUN specification (3489bis) itself, I guess the outbound draft
> only needs to
> > refer to 3489bis and "apply" it to SIP, e.g. by defining
> the keepalive
> > URI parameter.
> > 
> > 
> > Q2:
> > -----
> > 
> > If a client supports STUN for keep-alive, but not the other
> parts of
> > the
> > outbound extension (instance-id, reg-id etc), it will not
> insert the
> > instance-id etc, but it will still include the 'keepalive' 
> URI parameter.
> > 
> > Now, the outbound draft does not FORBID this, as far as I
> can see, but
> > I
> > wonder if we more clearly should point that out in the draft.
> > 
> > OR, the SIP usage of STUN keep-alive should be described in
> a separate
> > draft, now when the usage itself is part of 3489bis.
> > 
> > OR, if I only use STUN for keep-alive, without the rest of the 
> > outbound stuff, should I not use the 'keepalive' parameter in the
> first place?
> > 
> > 
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _______________________________________________
> > 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
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   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
> 

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Wed, 21 Jun 2006 10:12:09 -0700

On Jun 21, 2006, at 9:57 AM, Christer Holmberg ((JO/LMF)) wrote:

> There must also be a way for the edge proxy to indicate to the  
> client that it supports the STUN keep-alive usage. Because, if the  
> other outbound features aren't supported/requested, there will be  
> no "outbound" in the Supported header of the registration response.

this is done with the keepalive=stun parameter in the URI for the  
edge proxy

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 21 Jun 2006 12:59:00 -0500

I guess it could also be configured in the phone (STUN-in-SIP == TRUE).

But if we want to have the keepalive=true in the URI as mandatory, I'm
perfectly happy with that. It just means that instead of configuring
it seperately, it's inferred from the URI, which is better because it
is one less thing to worry about.

That's exactly the type of thing that I'd like to see in the paragraph.

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Wednesday, June 21, 2006 10:12
> To: Christer Holmberg ((JO/LMF))
> Cc: [email-masked]; Audet, Francois [SC100:3055:EXCH]

---

From: Dean Willis <[email-masked]>
Date: Thu, 22 Jun 2006 10:56:28 -0500

On Jun 21, 2006, at 12:12 PM, Cullen Jennings wrote:

> _

I have to admit, I'm a little queasy about this.

In the model of the world I hold in my head, a URI is much like a  
"function call". The parameters in a URI are information being  
provided to the  function, i.e., to the target of the URI.

Encoding things ABOUT the behavior of the called function that need  
to be known to the caller in those parameters just seems very backwards.

That's like asking a C programmer to know that a given function will  
return the cube of the first parameter because the second parameter  
is "cubed", when that second parameter has no impact whatsoever on  
the execution of the function and is there only to inform the user of  
the function about what the function does.

So what happens when a client that is constructing a proxy-URI  
decides to tack on a keepalive=stun parameter, and the proxy doesn't  
support keepalive via stun? Does the proxy reject a REGISTER request  
that contains this parameter if it doesn't support it?

--
Dean