[SIPForum-techwg] IP PBX / SP Interop Draft Version 5 propose d edits (update)
Elwell, John
john.elwell at siemens.com
Sat Mar 4 16:12:45 EST 2006
Chris,
I agree with all your recommended dispositions. See my earlier email for my
opinion of the one in blue.
John
_____
From: Chris Sibley [mailto:Chris.Sibley at cbeyond.net]
Sent: 03 March 2006 20:24
To: SIP Forum Tech WG
Subject: [SIPForum-techwg] IP PBX / SP Interop Draft Version 5 proposed
edits (update)
Added voting item for the updates to the NAT / Firewall traversal section as
requested (in BLUE).
Thanks,
--Chris
_____________________________________________
From: techwg-bounces at sipforum.org [mailto: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.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
------------------
Changes to the Firewall and NAT Traversal Section
Rohan Mahy wrote:
"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 forSIP
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)"
Hadriel Kaplan wrote:
" Can you also add a vote for whether or not to add Rohan's addition to
section 8? I did not hear anyone else agree to it, and I strongly disagree
to it.
There is no service provided/documented by this interop spec that requires
this addition to be met, and there's a large sector of service providers and
enterprises that can not and do not wish to meet it. Normally I would not
care if the doc said so because that sector of operators would simply ignore
it, but for this particular requirement it would potentially break
interoperability and suggest support for mechanisms which are not defined in
this document.
It also references 2 IETF documents which are in draft form only - which I
thought we were trying to avoid in this doc?"
Recommended Disposition: NONE - A "yea" vote means keep the change, a "nay"
vote means to strike the text in the final draft.
_____
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/20060304/8a431e18/attachment.html
More information about the techwg
mailing list