[SIPForum-techwg] IP PBX / SP Interop Draft Version 5 proposed edits
Chris Sibley
Chris.Sibley at cbeyond.net
Mon Mar 6 14:51:21 EST 2006
IP PBX / SP Interop WG team members,
Just a reminder to send me your votes for the following items ASAP (if
you have a preference either way). The deadline for submitting a
"proposed final draft" is this Wednesday (3/8), so I would like to have
your feedback as much before that date as possible (in order to allow
enough time for editing).
If don't vote on a particular issue and it comes down to a tie, he who
has the pen rules. ;-)
--Chris
_____________________________________________
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Chris Sibley
Sent: Friday, March 03, 2006 12:52 PM
To: 'SIP Forum Tech WG'
Subject: [SIPForum-techwg] IP PBX / SP Interop Draft Version 5 proposed
edits
IP PBX / SP Interop WG team members,
Following are the "top" issues derived from the "master list" of 2/27 -
3/2 comments. Please give them a quick read and respond to each with a
"yea or nay" vote on the recommended disposition.
After this round of edits/discussion has been completed, I will publish
a final list of issues still requiring discussion (also compiled from
the "master list").
Thanks!
--Chris
-----------------------
RFC 3265 (Session Initiation Protocol (SIP)-Specific Event Notification)
Support
Ernst Horvath wrote:
"I would like to see the following RFCs removed from the table in
section 5: 3265, 3515, 3842, 3891, and 3892. The reason is that there
are no use cases specified for these extensions in the rest of the
document, and it is unreasonable to mandate global conformance to a
generic mechanism like REFER or the event framework. (Which role is
mandatory - subscriber, notifier or both - for which entity? Which
methods can be referred, in which direction? Etc.)"
Cullen Jennings wrote:
"Why would you need 3265 - is this just for MWI"
Rohan Mahy wrote:
"Why is the SAS required to implement MWI? this is not motivated in the
text. recommend deleting the entire line."
Recommended Disposition: Remove the requirement for RFC 3265 from the
specification.
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------
RFC 3892 (The Session Initiation Protocol (SIP) Referred-By Mechanism)
Support
Ernst Horvath wrote:
"I would like to see the following RFCs removed from the table in
section 5: 3265, 3515, 3842, 3891, and 3892. The reason is that there
are no use cases specified for these extensions in the rest of the
document, and it is unreasonable to mandate global conformance to a
generic mechanism like REFER or the event framework. (Which role is
mandatory - subscriber, notifier or both - for which entity? Which
methods can be referred, in which direction? Etc.)"
Cullen Jennings wrote:
"I might be wrong but I think that 3892 requires S/MIME - I doubt you
want to do that "
Rohan Mahy wrote:
"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)."
Recommended Disposition: Remove the requirement for RFC 3892 from the
specification
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------
Call Progress Tones
Ernst Horvath wrote:
"I have a real problem with section 15.1. The generation of local tones
is an implementation matter and most likely subject to diverse
national regulations. Therefore this section should really be outside
the scope of this specification."
Cullen Jennings wrote:
"The call progress tones are US only. This seems really bad for a sip
forum document. I would be happy to contribute a list of other tones if
you would like :-)"
Rohan Mahy wrote:
"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."
Recommended Disposition: Remove the specific call progress tone
information and replace with a general statement that PBX systems SHOULD
generate some form of call progress tone.
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------
CDR Issues
Hadriel Kaplan wrote:
"The third paragraph [of section 9.1] confuses me greatly. I am not
clear what CDRs have to do with interoperability. If the service
provider chooses not to charge an Enterprise for anything, then they
don't comply with this spec? (they won't stay in business for long, but
that's another problem) It also implies a problem: how will the SAS know
that a call truly came from an Enterprise's PBX, when it went through
the service provider's SPS. It then lays out a solution for that by
saying information identifying the Enterprise must be extracted from the
cert and signaled to the SAS (somehow). That seems out of scope for an
interop spec - if the service provider wishes to identify the enterprise
PBX call through internally secured charging vectors, or call-ids
combined with p-asserted-ids, or whatever, it's up to them. It won't
impact interoperability unless you want the enterprise PBX to send some
special header for this."
Hadriel Kaplan wrote:
"Bullet-4 of section 9:
I'm pretty sure an interop spec should not be specifying what fields a
service-provider should populate their CDRs with?"
Ernst Horvath wrote:
"Section 9.1, bullet 4. This seems to relate to the interface between
Sip proxy server (on the SP side) and the SIP application server. I
believe this interface is outside the scope of this document."
Recommended Disposition: Remove all references to population of CDR data
from the specification.
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------
Requirement for STUN Support on the Firewall
Hadriel Kaplan wrote:
"The diagram and text discuss a STUN server as an optional,
non-mandatory element, yet the first paragraph of this section says the
diagram outlines the minimal set of elements required to support the
spec.
The diagram also has a dotted line to enterprise IP Phones, presumably
for their use to learn and open pinholes for publicly routable media
address/ports. However the rest of the document does not distinguish
between IP Phones and a PBX, but rather treats them as one logical
system - in fact that's specifically called out in the definitions
section for IP PBX and IP Phones. Further, section 8 suggests service
provider firewalls be STUN friendly, yet at no time does it say that
service providers are recommended to use STUN, nor is that communication
path in the diagram.
In essence, it is simply one example method, as enum was in section 10
for number location. It should be up to the Enterprise how they want to
learn public addresses to use. All you care about for interop purposes
is that the addresses presented to the service provider and vice-versa
are publicly reachable ones.
Given that, and given that the SIP message details inherent in actually
having IP Phones off an enterprise proxy/pbx are not really addressed in
this document, I recommend you remove the STUN server from the diagram
and section 5 standards list."
Hadriel Kaplan wrote:
"I still find it odd for an SP-to-Ent interop spec to tell an enterprise
that they SHOULD do something on their firewalls, when that something is
only
needed if they choose to fix something a certain way, and the way in
which the fix it is up to them entirely and has no bearing on
interoperability and is not defined in the spec itself.
It's like saying "your firewalls SHOULD support being a DHCP server",
because after all the SIP PBX and phones need IP Addresses and DHCP is a
way to get them, and some firewalls can be one.
Especially when you define the STUN server to be in the DMZ, whereas it
could be implemented inside the firewall itself, or on the public side
of a
firewall. A DMZ is not on the public side of a firewall - and it may
not even be public addresses. I'm not clear how STUN would even work in
a
traditional DMZ. Sending packets from inside to a DMZ box, if even
allowed, would not open any holes in the firewall to the public internet
and would not provide you with the same public address/port for such."
Janne Magnusson wrote:
"A STUN friendly firewall must be a full cone NAT firewall and that are
not common in enterprise environments as the security is much better
with a symmetric NAT firewall.
The STUN friendly firewall requirement is only valid if STUN is used, in
other cases should the enterprise be free to choose firewall as they
like. In most cases will an enterprise want to keep the existing
firewall and requirements like the suggested will hamper enterprises
willingness to implement SIP PBX technology.
I suggest that the last paragraph is removed. It is a pretty obvious
requirement if you choose to implement a STUN solution that all network
elements must be STUN friendly."
Recommended Disposition: Remove the requirement for the firewall to be
STUN-friendly.
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------
Requirement for Outbound Proxy Configuration on the SIP Application
Server
Ernst Horvath wrote:
"In the 2nd paragraph of 6.1 and 3rd paragraph of 6.2, it is mandated
that an FQDN is configurable for an outbound proxy. Why is it not left
as an internal matter how the proxy is addressed inside its own domain,
e.g. by configuring its IP address?"
Hadriel Kaplan wrote:
"Like Ernst, I do not understand why an interop spec is mandating
internal routing mechanisms in the service provider's network. Calls
that are routed for termination from the SP's SAS to its SPS may be done
through numerous means, one of which may be FQDN-based. It will not
impact interop between the SP and Enterprise how this is done."
Recommended Disposition: Remove the requirement from the specification.
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Chris Sibley
Sent: Friday, March 03, 2006 11:47 AM
To: SIP Forum Tech WG
Subject: [SIPForum-techwg] IP PBX / SP Interop Draft Version 5 "preview"
andnext steps...
IP PBX / SP Interop WG team members,
I have completed making all discussed changes from the 1/27 - 2/26
comment period. I have also completed making many of the smaller changes
requested from the 2/27 - 3/2 comment period (the full list of changes
made can be found at the end of this message).
A "preview" of the current working text is available for your review at
the following URL:
http://data.memberclicks.com/bbattach/128012/preview--sf-draft-twg-IP_PB
X_SP_Interop-sibley-v5--preview.pdf
As I indicated yesterday, I have compiled a "master list" of contributor
comments from the 2/27 - 3/2 time period. From this list, I have
extracted the set of issues that more than one person commented on.
As a next step I would like to see if we can get to a quick consensus on
these "top" issues so that I can go ahead and make the necessary changes
to the working draft.
I will be sending out a separate email in a bit that contains this list
of issues, the applicable comments made by each of the contributors, and
my recommendation for how to proceed on each. If you would, please take
the time to give the recommendation for each issue a quick "yea or nay"
vote so that I can quickly gauge the group's overall consensus on these
particular issues.
Finally, after this voting round is done, I'll send out a consolidated
list of the remaining items from the "master list" that still require
discussion and we can try to hammer those issues out.
Thanks!
--Chris
----------------
Draft Version 5 (preview release) changes
Section 1, Introduction
* Added statement to clarify that the primary service intended for
use by the spec is audio-based PSTN call origination/termination
* Added references to ITU-T Recommendations in addition to IETF
RFCs
* Added following statement to 3rd paragraph: "Note that this
document does not preclude or discourage the negotiation of additional
functionality."
* 3rd paragraph: s/This SIP Forum recommendation is proposed to
help address the issue./This SIP Forum document aims to address this
issue./
* 3rd paragraph: s/for predictable interoperability between/for a
predictable interoperable scenario between/
Section 3, Definitions
* Updated reference architecture drawing to show use of STUN
between PBX and STUN server (in addition to IP phones)
* Broke out the reference architecture drawing and the definitions
into separate sections
* Added definition for Application Layer Gateway
* s/the minimal/common/
Section 4, Key Assumptions and Limitations of Scope
* Added statement to clarify that the primary service intended for
use by the spec is audio-based PSTN call origination/termination
* Modified item #6: s/911 issues/calling issues, for example
routing to national emergency numbers such as 911, 112, 999, or 000, /
Section 5, Standards Support
* Added RFC 2782 as MANADATORY requirement for the SPS
* Changed column title 'RFC #' to 'Standard ID'
* Legend: s/(Receive only)/(at minimum to Receive)/
Section 6.1, (Locating SIP Servers) Enterprise Requirements
* Spelled out FQDN.
* 4th paragraph: changed AOR references to URI
* Changed wording in last paragraph from "register one or more
AORs" to "register a contact URI against one or more AORs".
* s/operate/ensure the existence of/
Section 6.2, (Locating SIP Servers) Service Provider Requirements
* 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, Signaling Security
* Updated text to require the use of canonical hostnames by the
SPS in the 'Via:' and/or 'Route:' SIP header fields.
* 5th paragraph: s/matches the server's host name or SIP
URI/matches the host portion of the target URI/
Section 8, Firewall and NAT Traversal
* Removed requirement that symmetric NATs must not be in the
communications, and that SIP ALGs should be disabled.
* Modified text to reflect the fact that the specification does
not exclude the use of any particular NAT traversal method (e.g. static
config, SBC, SIP-aware firewall.)
* Added clarification that IP addresses contained with SIP message
bodies as well as headers must be publicly routable addresses.
* Added requirements for SIP Intermediaries
Section 9.1, Authentication of the Enterprise by the Service Provider
* Minor text change ("The username supplied..." -> "The
authentication username supplied...")
* Added requirement to challenge the REGISTER request (in addition
to INVITES)
Section 10, Enterprise PSTN Identities
* Changed references of Address of Record / AOR to URI.
Section 11, Enterprise URI Formatting and Addressing
Rules
* Added statement that both open and closed numbering plans must
be supported.
* Added guidance for formatting the Request-URI field
Section 11.1, (Enterprise URI Formatting and Addressing Rules) 'From:'
Field
* Clarified the text to indicate that Option 1 is the preferred
method.
Section 11.2, (Enterprise URI Formatting and Addressing
Rules) 'To:' Field - PSTN Destinations
* Corrected URI examples in 11.2.1 and 11.2.2 (added international
prefix symbol and ;user=phone tag where applicable)
Section 11.3, (Enterprise URI Formatting and Addressing
Rules) 'To:' Field - Emergency Services Destinations
* s/ALI/emergency location information/
Section 12, Service Provider URI Formatting and
Addressing Rules
* Added guidance for formatting the Request-URI field
Section 12.1, (Service Provider URI Formatting and
Addressing Rules) 'From:' Field
* Added second option for anonymous URI format (to make compatible
with Identity: header)
Section 12.1.1, (Service Provider URI Formatting and
Addressing Rules) ('From:' Field) Option 1: Utilizing the 'From:' and
'P-Asserted-Identity:' SIP Header Fields
* 3rd paragraph: s/"Trust Domain"/"Trust Domain", as defined in
RFC 3325/
Section 13, Quality of Service Considerations
* Removed unnecessary statement indicating that the SP and
Enterprise must agree on settings if the recommended values are not
used.
Section 14.2, CODEC Support and Media Transport
* 2nd paragraph: s/terminates RTP traffic MUST/terminates RTP
traffic over UDP MUST/
Section 14.3, Transport of DTMF Tones
* Clarified that TGs must support RFC 2833 with any codec
Section 14.4, Echo Cancellation
* Clarified that some of the requirements only apply to devices
that supports fax and/or modem transmissions.
Section 14.5, Fax and Modem Calls
* Clarified that some of the requirements only apply to devices
that supports fax and/or modem transmissions.
* 2nd paragraph: s/SIP RE-INVITE method/SIP reINVITE request/
* 2nd paragraph, appended to end: " or SIP UPDATE request as
described in RFC 3311 [13]."
Section 16, References
* Added ITU-T Recommendation T.38 to the list of references and
tagged the text as applicable
Section 17, Contributors and Contact Information
* Updated contributor contact information
* Changed 'Email:' to 'mailto:' in contributor contact information
section
Miscellaneous
* Minor wording / grammar fixes
* Replaced all occurrences of "calling name information" with
"display name information"
* Replaced all occurrences of AOR and address of record with "URI"
* Changed all references of "CODEC" to "codec"
<< File: ATT177589.txt >>
**********************************************************************
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
**********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20060306/fec6e74a/attachment.html
More information about the techwg
mailing list