[SIPForum-techwg] Comments on IP PBX Interop - draft 3

[Chris Sibley]

Hi Joanne,

Thanks for the feedback! Comments inline below..

Thanks,

--Chris

> 

**********************************************************************
This email may contain confidential information. If you are not
the intended recipient, please advise by return email and delete
immediately without reading or forwarding to others.
 - Cbeyond 
**********************************************************************-----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On
> Behalf Of Joanne McMillen
> Sent: Wednesday, January 04, 2006 4:55 PM
> To: SIP Forum Tech WG
> Subject: [SIPForum-techwg] Comments on IP PBX Interop - draft 3
> 
> Hi all,
> 
> I finally made it through all the discussions and have a few
additional
> comments
> and a few questions:
> 
> Section 8 - number 3, this sounds like an implementation directive.
> Shouldn't
> we change
> 
> "MUST be explicitly disabled by manual configuration" to "MUST be
> transparent"?
> 

If the specification's guidelines for NAT traversal are followed, there
should be no need for the use of an ALG. Previous discussions on this
topic indicated a strong consensus that ALGs cause more problems than
they solve and thus deserved the explicit reference (to being disabled).


> 
> 
> Section 9.1 - both comment and question. Based on all the discussions
I
> thought the group had
> 
> come to consensus on TLS being the preferred solution yet this section
> merely states two
> 
> alternatives without mandating either. One should be required. My vote
is
> TLS. Or is the
> 
> intent here to require the SP to accomodate both? This needs
> clarification.
> 

TLS is required to secure the signaling path between the Enterprise and
SP (section 7), regardless of which authentication method is chosen by
the SP (section 9). 

> 
> 
> Section 9.2 - It's unclear why this is RECOMMENDED functionality -
please
> add
> 
> a few words to clarify. It starts out by saying the SP SAS is going to
be
> 
> authenticated, but then goes on to explain that in reality, it's only
the
> SP
> proxy
> 
> that's being authenticated - it's confusing. I'll wait for the
compelling
> 
> arguments I'm sure will occur, but right now I would see this as a MAY
> kinda
> thing. ;-)
> 

The requirement to authenticate the SP is recommended because the
Enterprise SIP Proxy Server will (in general) accept calls from any
other proxy targeted for a user on the Enterprise domain. However, in
some cases, the Enterprise may not want to accept calls from just any
proxy.

To help illustrate, consider the case of a small business with an IP PBX
that only wants to receive calls (on the PBX's external SIP interface)
from their ITSP, perhaps because they want to avoid "SIP spam" from the
Internet and the SP offers such a service. In this case, the SPS would
need to authenticate that the incoming SIP messages from the SP are in
fact where they "say" they are from (e.g. the service provider's SPS). 

The current draft text is trying to convey that if the Enterprise wants
to perform this type of authentication, then it should be done using the
information contained in the digital certificate used by the SP to
establish the TLS connection.

> 
> 
> Section 10 - HIGHLY RECOMMENDED - we ought not to be uing terms not
> defined
> 
> in RFC 2119. Or, add the definition to
> 
> section 2. However, I see no need to introduce new terms.
> 

Fair enough. Assuming there are no objections, I'll make the change in
the next revision.

> 
> 
> Section  11.1.2 - number 2 - this was raised against draft 2 as well
and I
> think by Ernst again for draft
> 
> 3 so let me just jump on board too so we are sure it doesn't get
> overlooked.
> The PBX cannot be required
> 
> to do this except when local policy of some kind results in wanting
the id
> kept private. This is not always the case.
> 

The use of P-Preferred-ID, in conjunction with the 'Privacy=id' field is
for two specific use cases. 

>From section 11.1.2, "This method SHOULD be used in situations where the
Enterprise wants calls from its users to appear to originate from a
common number (i.e. shared group appearance) or desires to present an
anonymous identity for the call while still retaining the ability to
receive services from the Service Provider for individual PSTN
identities."

In both of these cases, the use of 'Privacy=id' is the correct thing to
do (so that the PSTN endpoint receives the caller ID information
contained in the FROM field, not the information contained in the
P-Preferred-ID field.) 

> 
> 
> Section 11.2 - first paragraph - bit confusing - and I'd like to get
rid
> of
> UNLESS. So, how about
> 
> changing the wording to be the same as the case below it? "If the PSTN
> caller has suppied their E.164 address and
> 
> did not request calling number privacy,  SIP Applications servers MUST
> blah,
> blah"
> 

Good suggestion. I'll make the change in the next release.

> 
> 
> Section 11.4 - the group has still not reached consensus on this -
> correct?
> 

We haven't received official consensus on it yet, but I think we are
close. Do you have any specific objections?

> 
> 
> Section 14.3 - can we please change "AS WELL AS" to "and MUST support
the"
> so it's more clear there are two
> 
> actual requirements here?
> 

Another good suggestion. I'll make the change in the next release.

> 
> 
> Section 15.1 - NOTE - perhaps this is a nitpick, but I find it strange
to
> have a recommendation in a note.
> 
> Can we just make this mainstream text? There's also another case of
HIGHLY
> RECOMMENDED in this section.
> 

I agree that we should make the note mainstream text instead. I will
also change 'HIGHLY RECOMMENDED' to 'RECOMMENDED' in the next draft.


> 
> 
> Joanne
> 
> 
> 
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:
> http://sipforum.org/mailman/listinfo/techwg