[SIPForum-techwg] IP PBX / SP Interop Draft Version 5 proposededits (update)
Chris Sibley
Chris.Sibley at cbeyond.net
Wed Mar 8 17:16:16 EST 2006
Joanne, John,
I agree and will make the requested change.
Thanks!
--Chris
_____
From: Elwell, John [mailto:john.elwell at siemens.com]
Sent: Wednesday, March 08, 2006 4:39 PM
To: Joanne McMillen; Chris Sibley; SIP Forum Tech WG
Subject: RE: [SIPForum-techwg] IP PBX / SP Interop Draft Version 5
proposededits (update)
I would quite like to add the words proposed by Joanne.
John
_____
From: Joanne McMillen [mailto:joanne at avaya.com]
Sent: 08 March 2006 16:44
To: Chris Sibley; SIP Forum Tech WG
Subject: Re: [SIPForum-techwg] IP PBX / SP Interop Draft Version
5 proposededits (update)
Chris,
I agree with all your recommendations and also am OK with adding
Rohan's points
(with the latest agreed to wording).
I could not access the preview draft 5 for some reason, but have
an additional comment
that I'll make against draft 4 instead (since the text in 5 is
probably the same).
Sections 6.1 and 6.2 - registration:
Granted, registration is not an enterprise requirement, but I'd
like to see some wording
tightened up in section 6.2 such that it does not get turned
into one in practice.
Can we make the following change:
"SIP Application Servers MUST be prepared to accept (but
MUST not require) registrations for any valid AOR that
the Service Provider has
assigned to an Enterprise. This interface specification does
not define any specific action that is triggered by a successful
registration; however one possible use of this information
might be to update the SIP Application Server's "default" IP
address for the PBX."
Does anyone have a problem with that change or something
similar?
Joanne
----- Original Message -----
From: Chris Sibley <mailto:Chris.Sibley at cbeyond.net>
To: SIP Forum Tech WG <mailto:techwg at sipforum.org>
Sent: Friday, March 03, 2006 1:24 PM
Subject: [SIPForum-techwg] IP PBX / SP Interop Draft
Version 5 proposededits (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] 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
_____
_____
_______________________________________________
techwg mailing list
Send mail to: techwg at sipforum.org
Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg
**********************************************************************
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/20060308/d2d59174/attachment.html
More information about the techwg
mailing list