Subject: RE: [Sipping] WGLC: draft-ietf-sipping-sbc-funcs-00.txt

From: "Michael Procter" <[email-masked]>
Date: Tue, 5 Dec 2006 09:07:35 -0800

Here are my initial comments following a review of
draft-ietf-sipping-sbc-funcs-00.txt.  I have tried to remove any
comments that duplicate Francois comments.

Draft:  		draft-ietf-sipping-sbc-funcs-00.txt
Reviewer: 		Michael Procter
Review Date:	5 Dec 2006
Review Deadline: 	20 Dec 2006
Status: 		WGLC

Summary:	
This draft is on the right track but has open issues, described in the
review.

General:
I found the title somewhat misleading.  Instead of a collection of
requirements obtained from SBC deployments, this document seems to be
a collection of useful SBC techniques.  The requirements in section 4
seem
to be added as an afterthought, rather than being the main purpose of
the
document as suggested by the title.  The introduction states that the
goal
of this document is 'to describe all the functions of SBCs', which seems
to
conflict with the title.

I found that the division of each function in section 3, into 'General 
Information', 'Architectural Issues' and 'Example' useful.  But the 
'General Information' section seems to mix statements of the problem
with statements of approaches to fix it.  Maybe clearly separating out
what
problem is to be solved from how it is solved would be helpful.

3.1.3:
Given the discussion of Via handling, it would be useful to see this
used
in the example, in addition to Record-Routes.

3.2:
CODEC restriction strikes me as being one of the more important
applications of traffic shaping, but it only gets mentioned half-way
through the Example section.  I would find it helpful to have it
mentioned
in the General Information section, as a statement of the sort of
problem
being tackled by this section.

3.4.1:
This section discusses NAT binding maintenance, and then throws in a
comment at the end about 'other measures may be taken'.  It strikes me
that
in a section about NAT traversal, some discussion of techniques such as
Path, or Contact rewriting should be included, or some similar 
discussion.  Whilst there are some comments about this subject in the 
'Topology hiding' section, I'm not sure that that is an obvious place to
look.

3.4.3:
The last comment says:
	Naturally also other measures need to be taken in order to
	enable the NAT traversal...
Can they be listed at least?  The introduction states that 'the goal of
this document is to describe all the functions of SBCs', after all.

3.5.3:
'the SBC first identifies the caller'.  Since this occurs before the
INVITE
is received, I think a little more explanation is required.  If this is
TLS
or TCP specific, then that should be called out.  If the action is
really
performed once the INVITE has been received but before additional
processing, then the diagram and text should reflect this.  The missing
ACKs in the diagram are minor, but such things have caused confusion in
the
past.

3.6:
This section doesn't seem to have much content apart from a list of bugs
that can be worked around.  Whilst this list may be a good source of
stories, do they all need to be listed?  Can a couple be selected as
indicative of the sorts of incompatibility that can be fixed, and the
section shortened?

3.7:
I am not sufficiently experienced with secure media to be able to review
this section, although I note that the ACKs are missing from the call
flow.

Minor
=====

2.2, third line:
'to the operator' should read 'to the operator's'

3, fourth line:
'explanation on any impact' should read 'explanation of any impact'

3.1.2, second para, first line:
'Unifor Resource Indetifiers' should read 'Uniform Resource Identifiers'

3.1.3, second para, second line:
'is receiving an INVITE' might be clearer as 'receives an INVITE'

3.1.3, fourth para, fifth line:
'then restarts losing state,' might be clearer as 'restarts, thus losing
state,'

3.1.3, last para, first line:
'topology hiding, in some cases,' might be clearer as 'topology hiding.
In
some cases,'

3.2.1, first para, fourth line:
'subscibers' should be 'subscribers'

3.2.1, first para, fifth line:
'differently than' should be 'differently to'

3.2.3, first para, fifth and sixth lines:
'user agent', or 'user-agent', but not both!

3.2.3, second para, seventh line:
'alarming' in this context is jargon.  Prefer 'raise an alarm'.

3.2.3, third para, second line:
'from the one network' might be 'from the outer network', but this isn't
clear from context. 

3.6.1, first para, third line:
'many client as possible' should read 'many clients as possible'

Regards,

Michael Procter

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Kapil Nayar <[email-masked]>
Date: Tue, 5 Dec 2006 21:17:10 +0000 (GMT)

Hi

Consider a scenario:
1. Transferor initiates a new call towards the
transfer target. Transfer target replies with 302 but
with multiple contacts.
3. Transferor forks the call to the multiple contacts
which are alerted. Transferor completes the transfer
at this point through REFER message to transferee.

Is it legal to:
a. Include multiple "Refer To:" headers with replaces
parameters.
b. Expect the transferee to send individual
Invite-w-replaces to multiple contacts based upon each
"Refer To:" header.
c. Expect the transferee to terminate the call when
one of the transfer targets answers the call.
d. Does the NOTIFY from transferee to transferor needs
to distinguish between the individual "Refer To:"
sessions?

Any pointers to drafts/ RFCs covering this scenario(s)
would be welcome.

thanks,
Kapil

Send instant messages to your online friends http://uk.messenger.yahoo.com

---

From: [email-masked]
Date: Wed, 6 Dec 2006 18:44:56 -0500

From: Kapil Nayar <[email-masked]>

   Consider a scenario:

   Is it legal to:

No.  As Kapil notes, it is not legal to include multiple "Refer-To:"
headers, per RFC 3515.

In addition, as Brett notes, it is not legal for the transferee to
send an INVITE-with-Replaces to the transfer target, as the transfer
target is participating in an early dialog that it did not initiate.

Dale

---

From: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Fri, 08 Dec 2006 11:21:30 +0200

Hi Michael,

Thanks for the review. I'll take your comments into consideration on the
next revision of the draft.

-- 
Jani