[SIPForum-techwg] comments on PBX-SP v4

[Rohan Mahy]

Hi,

I reviewed version 4 of the document with an eye towards scope, global 
applicability, and consistency with specifications already developed or 
in the process of development in the IETF.  My comments are divided 
into functional and detail comments:

Functional comments:
- append to 3rd paragraph of intro:
Note that this document does not preclude or discourage the negotiation 
of additional functionality.

- Section 4 item #6  (globalize US centric reference)
s/911 issues/calling issues, for example routing to national emergency 
numbers such as 911, 112, 999, or 000, /

- Section 5 - Legend
s/(Recieve only)/(at minimum to Receive)/

- requirement for MWI
Why is the SAS required to implement MWI?  this is not motivated in the 
text.  recommend deleting the entire line.

- requirement for Referred-By
This is also not motivated by the text.  Referred-by strongly 
recommends the use of auth-id bodies signed with S/MIME.  I am not 
aware of *any* implementations of this portion of the Referred-By spec. 
  If we recommend Referred-By, we at least need to specify that this 
part is not required (and why).

- requirement for the early-session disposition
This recommendation is well motivated by the text.   However, can we 
identify two interoperable implementations of the early-session 
disposition? If not, we will need to remove it.

Section 6.1, 1st para  (self-consistency)
s/operate/ensure the existence of/

Section 6.2 last paragraph:
This implies some conflict with RFC 3263.  Is this what is intended?:
s/to update the SAS's default IP address for the PBX/to update a DNS 
entry associated with the PBX in a DNS zone managed by the Service 
Provider./

Section 7 5th para:
s/matches the server's host name or SIP URI/matches the host portion of 
the target URI/

Section 8 item #2
s/Symmetric NATs/Symmetric NATs as defined in RFC 3489 [18]/

Section 8 item #3
we need to define an Application Layer Gateway back in section 3.  I 
propose:
"An Application Layer Gateway (ALG) modifies IP addresses and port 
numbers inside the payload of IP packets even when the corresponding IP 
packets are not addressed to the ALG. SIP ALGs do not follow the rules 
necessary to conform to any SIP role, for example, most SIP ALGs do not 
insert a Via header."

Section 8
propose we add a 4th item.  this was discussed very early, but was 
dropped.  this is consistent with our "do no harm" motto:
4) SIP intermediaries MUST NOT modify IP addresses or port numbers in 
the body or Contact header of any message if any of the following are 
true:
- The SIP message contains an "Identity" header (indicating use of the 
Identity extension)
- the Content-Type of the body or any of its subparts is 
"application/pkcs7-mime" or "multipart/signed" (indicating support for 
SIP S/MIME)
- any "application/sdp" body in the message contains any "a=candidate:" 
lines (indicating use of the ICE extension)
- all the "c=" lines in any "application/sdp" bodies contain only 
public IP addresses (indicating that another element has already 
ensured the addresses are correct).

Section 10 2nd and 3rd paras
- replace AOR or Address of Record with "URI".  Some of the SIP URIs 
used in the context of these paragraphs will be AORs.  Also note that 
there is some confusion over the meaning of the term AOR.  Some feel it 
refers to any long-term, stable identifier, while other believe it 
applies only to SIP URIs associated with a location service.  We should 
be conservative and use the correct and unambiguous term URI here.

Section 11.1.1 3rd para
add reference to RFC 3264 after the first use of the "Trust Domain"
s/"Trust Domain"/"Trust Domain", as defined in RFC 3264/

Section 11.3 (globalize US centric reference)
s/ALI/emergency location information/

Section 12.1 2nd para  (to be consistent with upcoming IETF specs)
we need to also allow an anonymous URI in this form as well.  This is 
allowed by RFC 3261 and required if the SP wants to use the Identity 
header.
From: "Anonymous" <anonymous@[domain name]>

Section 14.1 2nd para
Do we want to add that they MUST also send a:inactive/sendonly/recvonly 
?

Section 14.2 2nd para
s/terminates RTP traffic MUST/terminates RTP traffic over UDP MUST/

Section 14.3 1st para, 2nd sentence
clarify that TGs need to support RFC 2833 with any codec.

Section 14.5 2nd para
s/SIP RE-INVITE method/SIP reINVITE request/
append to the end
" or SIP UPDATE request as described in RFC 3311 [13]."

Section 15.1
The response code to tone mapping here is US centric and does not even 
accommodate variations among US phone systems (for example, some US 
phone systems use Fast Busy instead of SIT tone for "all circuits 
busy".
Ideally the tones generated by the PBX will be configurable.  I'm 
inclined to declare the specific tones out of scope.
I propose we
- leave the 2nd paragraph (starting "In the event")
- change the 5th paragraph to:
"PBX systems SHOULD generate some form of call progress tone for all 
provisional and non-repairable error response codes."
- and leave the remaining 2 paragraphs.

General
I think SIP Application Server (SAS) is vague enough and used for 
enough contradictory things that we should use a different name for it. 
  I propose "SIP Gateway Service (SGS)".

s/AOR/URI/ in a few other places.



NITS and small text proposals
Intro 3rd para:
s/This SIP Forum recommendation is proposed to help address the 
issue./This SIP Forum document aims to address this issue./
s/for predictable interoperability between/for a predictable 
interoperable scenario between/

Sect 3 (Definitions)
s/the minimal/common/

Sect 6.1 2nd para
spell out first use of FQDN (Fully Qualified Domain Name)

Sect 6.1 last para
s/register one or more Address of Records/associate one or more SIP 
URIs/

Sect 11.2
s/at least on of these/at least one of these/

General
s/CODEC/codec/g