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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 26 Jun 2006 10:16:28 +0200

Hi,

>>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?
>
>same thing that happens if the client decide to recode the URI in  
>ebcdic - it probably won't work. Of course any self respecting proxy  
>should not have problems if some random non sip message get sent to  
>it be that message a STUN message or just a random network scan probe.

[CHH] The problem is that, eventhough the NAT keep-alive would work, the
client would not be able to use the detect-if-the-NAT-has-rebooted
functionality, since it won't get any STUN responses back. The client
will of course detect that, since it doesn't get any STUN resposnes
back, but there should be a "nicer" way to be informed about that fact
that something isn't supported.

One problem is that the client may not have the edge proxy (I guess we
can still call it that, even if we ONLY talk about STUN for NAT
keep-alive, and not the rest of outbound) address information in "URI
format". It may use some other edge proxy discovery mechanism, which
only provides the IP address/port (no URI parameters etc) of the proxy
to the client. In that case the client will have to assume that the edge
proxy supports STUN, and insert the parameter in the URI created based
on the IP address of the proxy.

But, as Cullen said, the problem is that there may not be any other good
ways.

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Jun 2006 15:38:24 +0200

Hi,

I may have missed it, but is there a reason why the edge proxy itself couldn't, if it supports STUN NAT keep-alive, insert the keepalive parameter in the Path header URI?

The client, when receving the registration response, will then see whether the edge proxy supports it or not.

That would also work then the client does not have a full URI of the edge proxy (it may only have an IP address or FQDN, which is uses to build a URI).

Regards,

Christer 

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: 25. kesäkuuta 2006 2:05
To: Dean Willis
Cc: Christer Holmberg (JO/LMF); [email-masked]; Francois Audet
Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis

I understand people are uneasy about this - originally I proposed something else and got very strong feedback to do it exactly the way sigcomp does it. I don't see this problem in anyway different that sigcomp. We may have done sigcomp wrong but so far no one seems to come up with a concrete problem. It's pretty late to be thinking about starting to explore other ways that we might be able to do this. More inline.

On Jun 22, 2006, at 8:56 AM, Dean Willis wrote:

>
> On Jun 21, 2006, at 12:12 PM, Cullen Jennings wrote:
>
>>
>> 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
>>
>> _
>
> 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.

Interesting model - but I think I would need to consider the sip:  
part of the URI fits your model and neither does the ;lr

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

All the time we have functions return tokens that are passed back in on a later call but I'm not sure i find the analogy all that compelling.

> --
> Dean