Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 7 Jul 2006 20:06:57 +0300

IHi,

What if the client only gets IP address(es) of the edge proxy? Is each address treated as a URI?

As I've said earlier, a SIP URI is something the client creates, but it does not necessarily be what is configured (given as input, manually or using some other mechanism).

I've also indicated that there may be other mechanisms than "multi flow" to provide reliability. So, in those cases multiple flows may not be needed, but one may still want to use outbound.

Note tha I am NOT arguing against saying that a client must support the establishment of two flows.

Also, if a client uses STUN keepalive, but not the rest of outbound (instance-id etc) it would not make sense trying to send multiple registrations, since the registrar would not be able to differentiate the "flows". I think that needs to be clear in the spec, a part of defining the STUN keepalive as a standalone function.
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: Rohan Mahy <[email-masked]>
Date: Fri, 7 Jul 2006 23:11:16 -0700

Hi Christer,

It is near the end of a long day today, so I am having trouble 
understanding why we are still having this discussion.  I really do 
want to understand what you are trying to accomplish.  I am just 
relating a humorous thought that popped into my punchy brain as I sit 
here.

I have to admit that my initial reaction is that this is something like 
the following vignette.  A coach tells a runner about the new track 
about to be installed with black spongy rubber.  The runner asks can 
you please add a sprinkler system to it before it is installed?  The 
coach asks why and the runner responds that the black track will be hot 
to run on in bare feet.

Of course running on the track with bare feet is a perfectly 
acceptable, but running with shoes is certainly more common, possibly 
even recommended.  The new track will be a great improvement for 
everyone and will work with and without shoes.  However its unclear 
that the sprinkler system is really a good idea, that it will work, how 
long it will take to install, and how much it will cost.  It could be 
installed later if it turns out to be needed.  In the interim, folks 
with shoes and tough feet can use the track immediately.

On Jul 7, 2006, at 10:06, Christer Holmberg wrote:
> Hi,

the client needs to figure out how to derive a URI to place in its 
Route header or to use as a target for RFC 3263.  how this is done is 
up to you, but getting an IP address alone feels like getting running 
shorts and no shoes.

> As I've said earlier, a SIP URI is something the client creates, but 
> it does not necessarily be what is configured (given as input, 
> manually or using some other mechanism).
>
> I've also indicated that there may be other mechanisms than "multi 
> flow" to provide reliability. So, in those cases multiple flows may 
> not be needed, but one may still want to use outbound.

I still don't see the advantage of trying to do one flow "reliability" 
with outbound proxies only addressed by an IP address.  Why is going 
barefoot better than wearing sneakers?  I think I would need to see a 
full use case (a few paragraphs and maybe a simple drawing) to get what 
you have in mind.

> Note that I am NOT arguing against saying that a client must support 
> the establishment of two flows.

ok, good to know.

> Also, if a client uses STUN keepalive, but not the rest of outbound 
> (instance-id etc) it would not make sense trying to send multiple 
> registrations, since the registrar would not be able to differentiate 
> the "flows". I think that needs to be clear in the spec, a part of 
> defining the STUN keepalive as a standalone function.

I actually understand the motivation for this one.  The issue is how 
much of the STUN keepalive mechanism belongs in 3489bis, how much could 
go in outbound in a separate section (or a separate document), and how 
much is specific to outbound.  I think all the text about what you do 
when you try to setup a flow and it doesn't work (retry after x 
seconds...) is really very specific to multiple flows.  There is the 
binding request/response that belongs in 3489bis.  What is unclear to 
me is what else is left.  Certainly you need some part of a doc that 
defines the keepalive URI parameter and updates 3261 to say it ok to 
send STUN on the same port as SIP when you have positive knowledge 
(such as the keepalive parameter) that the server is ok with that.

thanks,
-rohan

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sat, 8 Jul 2006 21:47:22 +0200

Moving the discussion from the "[Sip] Re: A coment to draft-ietf-sip-outbound-04" thread:
 
Rohan wrote:
 
>much is specific to outbound.
 
My proposal would be:
 
3489bis:
-----------
 
- We pretty much leave the text as it is. 3489bis is not SIP specific, but we could say how it can be used to detect whether the NAT has re-booted (checking the XOR-xxx value in the STUN response). I believe that is currently said in the outbound spec, but it's not outbound specific. I don't have the specs in front of me, so I may be wrong...

Outbound spec:
----------------------
 
- The outbound spec refers to the SIP STUN keep-alive mechanism (no matter if described in the outbound draft or a separate draft), says that it MUST be used with outbound.
- That outbound related actions taken if the client detects (from the STUN response) that the NAT has re-booted.

Separate document OR separate section in the outbound spec:
-----------------------------------------------------------------------------------
 
- Here we define whatever option-tags and URI parameters are needed for the SIP usage of  STUN keep-alive (NOTE: outbound related option-tags etc are not defined here)
- Here we define how to use it for SIP, e.g. saying that the STUN messages are sent to the same port as the SIP requests
- Here we MAY say something about "generic SIP actions" if the client detects NAT re-boot, if there is something we don't think is outbound specific (need to think about that).

>I think all the text about what you do when you try to setup a flow and it doesn't work (retry after x seconds...) is really very >specific to multiple flows.
 
I agree. "Flow" is an outbound specific term, and has nothing to do with STUN keep-alive as such.
 
>There is the binding request/response that belongs in 3489bis.  What is unclear to
>me is what else is left.  Certainly you need some part of a doc that defines the keepalive URI parameter and updates 3261 to >say it ok to send STUN on the same port as SIP when you have positive knowledge
 
Yes. That is pretty much what I suggested above.
 
And, IF some new parameter is needed for the proxy to indicate whether it supports STUN or not (please let us have that discussion elsewhere - not in this thread :), it should also be defined here. 
 
But, IF we think that the indicate-what-a-proxy-support-and-does-not-support mechanism itself is GENERIC, and not only related to STUN (in future there may be other extensions where it's needed), that should of course then be described in a dedicated document. But, let's have that discussion elsewhere also :)
 
Regards,
 
Christer

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 8 Jul 2006 23:00:47 +0200

Christer,

And don't forget UA-UA keep-alives (and thus the need for a UAC/UAS to 
indicate support). Once the UA registers using outbound, at one point it's 
going to want to make a call (or subscribe, or whatever). I'd like to avoid 
a situation in which some proxy must always record-route for this to work 
(think eg about SIPSEC)

Also, I've been considering the following: what if we would reverse the 
client/server roles for STUN in outbound? Have the proxy initiate binding 
requests, and the UA answer them. Then the proxy can have more control over 
its load, and there is no risk that a non-outbound proxy gets STUNned. Just 
a thought...

Regards,

Jeroen

----- Original Message ----- 
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Rohan Mahy" <[email-masked]>; <[email-masked]>
Cc: "Miguel Garcia" <[email-masked]>; "Cullen Jennings" 
<[email-masked]>
Sent: Saturday, July 08, 2006 9:47 PM
Subject: STUN keep-alive: Where to document it? (was [Sip] Re: A coment 
todraft-ietf-sip-outbound-04)

Moving the discussion from the "[Sip] Re: A coment to 
draft-ietf-sip-outbound-04" thread:

My proposal would be:

3489bis:
-----------

- We pretty much leave the text as it is. 3489bis is not SIP specific, but 
we could say how it can be used to detect whether the NAT has re-booted 
(checking the XOR-xxx value in the STUN response). I believe that is 
currently said in the outbound spec, but it's not outbound specific. I don't 
have the specs in front of me, so I may be wrong...

Outbound spec:
----------------------

- The outbound spec refers to the SIP STUN keep-alive mechanism (no matter 
if described in the outbound draft or a separate draft), says that it MUST 
be used with outbound.
- That outbound related actions taken if the client detects (from the STUN 
response) that the NAT has re-booted.

- Here we define whatever option-tags and URI parameters are needed for the 
SIP usage of  STUN keep-alive (NOTE: outbound related option-tags etc are 
not defined here)
- Here we define how to use it for SIP, e.g. saying that the STUN messages 
are sent to the same port as the SIP requests
- Here we MAY say something about "generic SIP actions" if the client 
detects NAT re-boot, if there is something we don't think is outbound 
specific (need to think about that).

>I think all the text about what you do when you try to setup a flow and it 
>doesn't work (retry after x seconds...) is really very >specific to 
>multiple flows.

I agree. "Flow" is an outbound specific term, and has nothing to do with 
STUN keep-alive as such.

>defines the keepalive URI parameter and updates 3261 to >say it ok to send 
>STUN on the same port as SIP when you have positive knowledge

And, IF some new parameter is needed for the proxy to indicate whether it 
supports STUN or not (please let us have that discussion elsewhere - not in 
this thread :), it should also be defined here.

But, IF we think that the indicate-what-a-proxy-support-and-does-not-support 
mechanism itself is GENERIC, and not only related to STUN (in future there 
may be other extensions where it's needed), that should of course then be 
described in a dedicated document. But, let's have that discussion elsewhere 
also :)

Regards,

Christer