[SIPForum-techwg] Comments on IP PBX Interop - draft 3
Chris.Sibley at cbeyond.net
Thu Jan 12 14:50:31 EST 2006
Thanks for the feedback! Comments inline below..
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.
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
> 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
> and a few questions:
> Section 8 - number 3, this sounds like an implementation directive.
> we change
> "MUST be explicitly disabled by manual configuration" to "MUST be
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
> 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
> TLS. Or is the
> intent here to require the SP to accomodate both? This needs
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 -
> a few words to clarify. It starts out by saying the SP SAS is going to
> authenticated, but then goes on to explain that in reality, it's only
> that's being authenticated - it's confusing. I'll wait for the
> arguments I'm sure will occur, but right now I would see this as a MAY
> 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
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
> 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
> think by Ernst again for draft
> 3 so let me just jump on board too so we are sure it doesn't get
> The PBX cannot be required
> to do this except when local policy of some kind results in wanting
> 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
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
> Section 11.2 - first paragraph - bit confusing - and I'd like to get
> 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
Good suggestion. I'll make the change in the next release.
> Section 11.4 - the group has still not reached consensus on this -
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
> 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
> have a recommendation in a note.
> Can we just make this mainstream text? There's also another case of
> 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.
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:
More information about the techwg