Subject: [Sip] draft-ietf-sip-outbound

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sat, 25 Mar 2006 00:51:01 -0000

(as chair)

As a result of the face-to-face meeting held at IETF #65, we agreed in the room on the keepalive mechanism:

-	OS TCP KeepAlive should be used if the client supports it.
-	Need something more because OS TCP KeepAlive is not supported in every client OS.
-	Consensus to use STUN for UDP
-	Consensus to use STUN for TCP, with use of OS TCP keep alive above.

With these agreements the meeting also agreed that the document was ready for WGLC.

As a result of this Rohan has produced:

http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt

Unfortunately one of the agreements was left out of this update, and a number of NITS have also been identified.

Required Actions:

1)	Authors: Produce -04 version to take account of remaining issues where consensus exists and any NITS.

2)	Working group: Any dissent to the agreements listed above or do we have rough consensus to proceed according to the agreements made in the meeting

3)	Working group: Are we ready to move to WGLC. Please indicate if you consider this document needs more work preceding WGLC.

Pleaswe complete all these actions by 31st March 2006.

regards

Keith

Keith Drage
[email-masked]
tel: +44 1793 776249

_______________________________________________
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: "Frank W. Miller" <[email-masked]>
Date: Fri, 24 Mar 2006 21:36:32 -0500

> 2)	Working group: Any dissent to the agreements listed above or do we have rough consensus to proceed according to the agreements made in the meeting

I have dissent on the use of STUN exclusively for keepalive.  I believe
that a SIP based mechanism such as the PING draft I proposed is a better
solution.  The essence of my objection is that I think it is a mistake
to have both STUN and SIP residing on the same port.  I think this makes
little sense for three reasons: 1) its architecturally in conflict with
the way most other protocols are defined, i.e. each protocol generally
lives on its own port, 2) it unnecessarily complicates implementations
when there is a very simple way to do it within SIP, and most
importantly 3) it is going to make it very difficult to use STUN for the
same task with other protocols that will need keepalives.  Also, I don't
believe that the performance issues that have been put forth are
substantive enough to cause the architectural violations that result
from using STUN this way.

If the group is dead set on using STUN this way, the SIP way should at
least be acknowledged by 1) including a ;keepalive=ping tag for the URI
in the outbound draft and 2) allowing the PING draft to become an ietf
draft.  These actions place very little additional burden on
implementors and will allow the "market" to decide which is the right
one to be used operationally.

Dissent registered.

FM

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 25 Mar 2006 06:31:35 +0200

Drage, Keith (Keith) writes:

 > 3)	Working group: Are we ready to move to WGLC. Please indicate if
 > 3)	you consider this document needs more work preceding WGLC.

see ongoing discussion on auto-discovery of outbound-proxy-set.  the
document is not useful in practise without such a mechanism and you
cannot thus declare it out of scope.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 25 Mar 2006 11:34:49 +0100

> 3) Working group: Are we ready to move to WGLC. Please indicate if you 
> consider this document needs more work preceding WGLC.

Several comments:

3.4 - The case where a NAT device would be between the edge proxy and the 
registrar is out of scope? If so, this could be explicitly written. If not, 
there is more work to do...

4.4.1 - In addition to checking for 'keepalive=stun', suggestion to also 
check for 'Supported: outbound' in the OK response to REGISTER. This would 
avoid misconfiguration scenario's in which the UAC starts poking STUN 
packets at a registrar that does not expect them.

In fact, perhaps the check for Supported alone would be sufficient (and omit 
keepalive=stun altogether)

Jeroen

---

From: iPekka Pessi <[email-masked]>
Date: Thu, 30 Mar 2006 16:59:36 +0300

>3)	Working group: Are we ready to move to WGLC. Please indicate if you consider this document needs more work preceding WGLC.

I think the text discussing instance-id/reg-id and relationship between
outbound and gruu needs some dusting.

1. Is reg-id mandatory?

The section 4.1 says that UAC MUST include reg-id in Contact (unless it
is doing 3rd party registration, or so I interpret 4.1). I suppose the
contact with instance-id but no reg-id is just a gruu-hopeful, not
outbound. Perhaps outbound spec could mention that using instance-id
without reg-id in UAC and edge proxies is explained elsewhere.

In any case, the examples and overview only confuse when they explain
the usage without reg-id. So, I'd propose replacing the text in section
3.2:

   User Agents which form only a single flow continue to register
   normally but include the instance-id as described in Section 4.1.
   The UA can also include a reg-id parameter is used to allow the
   registrar to detect and avoid using invalid contacts when a UA

with

   User Agents which form only a single flow continue to register
   normally but include the instance-id and reg-id as described in
   Section 4.1. The reg-id parameter is used to allow the
   registrar to detect and avoid using invalid contacts when a UA

2. How bindings with instance-id are handled in registrar? 

The second paragraph in outbound-03 section 6.1 describes how a
binding with instance-id shuld be processed. If there is
instance-id the URI should be ignored when comparing and
reg-id/instance-id pair should be used instead.

My understanding is that the binding comparison in registrar is
used to locate the bindings that the REGISTER request updates,
like the first paragraph of page 66 in RFC 3261 describes. Is this
the comparison to which the second paragraph in 6.1 refers? Or
does the registrar still use the URI comparison when updating the
bindings but delay the pruning of bingings until the target-set
selection time?

So, if UA has registered contact 1 with instance-id A, reg-id 1
and URI U1, then registers contact 2 with instance-id A, reg-id 1
but URI U2, the new contact replaces old one. Or does it just keep
all the entries, but ignore contact 1 until contact 2 expires or
it is unregistered (like text in 3.2 implies)?

So, I propose that the intention is spelled out in 6.1, for instance
like this:

   combination of instance-id and reg-id. When searcing existing
   bindings to update, registrar matches a Contact header field with an
   instance-id with a current binding containg same instance-id and
   reg-id, regardless of the URI stored with the binding (the Contact
   URI is not part of the "key" for the binding). The registrar still
   stores the Contact header field value URI with the binding. 

Also, I'd propose updating the text in overview section. Replace 3.2
(page 7):

   the Contact header field.  If the instance-id and reg-id are the same
   as a previous registration for the same AOR, the proxy uses the most
   recently created registration first.  This allows a UA that has
   rebooted to replace its previous registration for each flow with
   minimal impact on overall system load.

with

   the Contact header field.  If the instance-id and reg-id are the same
   as a previous registration for the same AOR, the proxy replaces
   old registration with new one.  This allows a UA that has
   rebooted to update its previous registration for each flow with
   minimal impact on overall system load.

and this

   that has the same instance-id as the selected UA.  In general, if two
   registrations have the same reg-id and instance-id, the proxy will
   favor the most recently registered flow.  This is so that if a UA
   reboots, the proxy will prefer to use the most recent flow that goes
   to this UA instead of trying one of the old flows which would
   presumably fail.

with

   that has the same instance-id as the selected UA. The new
   registrations with same reg-id and instance-id will replace the
   old flows. This is so that if a UA reboots, the proxy will
   use only the most recent flow that goes to this UA instead
   of trying one of the old flows which would presumably fail.

3. Should registrar/edge proxy use outbound in absense of reg-id? (NO?) 

Gruu is relatively lightweight (adding the Path header to REGISTER)
compared with outbound (keeping connection, consume sockets) so I feel
that gruu should not require using outbound in edge proxy, especially if
the edge proxy is reachable from outside and can establish TCP
connections towards UA when needed. So, the requirement of caching the
connection 5.1 could be relaxed so that the flow-id would be required
only when there is both reg-id and instance-id in Contact of REGISTER
request.

4. What happens when an edge proxy closes the connection?
 
The last paragraph in 6.2 says that when the connecion is closed (FIN on
TCP, destination unreachable ICMP on UDP), the binding must be removed. 
Does this happen only when there is reg-id, or even without reg-id? Does
it happen with Path, or without Path?

--Pekka