[SIPForum-techwg] IP PBX / SP Interop Draft Version 5 propose d edits

[Elwell, John]

Rohan,

While I understand your technical motivation, we must be clear on the scope
of this interop spec. It is a specification of interworking between an IP
PBX and an SP, or in other words, between a proxy on the IP PBX side and a
proxy on the SP side (refer to the architecture diagram in the draft). So
what it defines is what goes across that interface. If the proxy on the
IPPBX side modifies these fields such that what is sent on the IP PBX side
of the proxy differs from what is sent across the interface to the SP proxy,
then that appears to be outside the scope of this specification. Likewise on
the SP side. So my vote is to exclude your proposed text.

John

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan at ekabal.com] 
> Sent: 03 March 2006 22:34
> To: Hadriel Kaplan
> Cc: 'SIP Forum Tech WG'
> Subject: RE: [SIPForum-techwg] IP PBX / SP Interop Draft 
> Version 5 proposed edits
> 
> Hadriel,
> 
> > 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.
> 
> Please motivate this statement.  Under what circumstances can 
> a service
> provider or enterprise intermediary safely modify the SIP 
> body when any of
> the conditions I mentioned are satisfied?  (For example, if 
> an Identity
> header is present, modifying the body or the contact will cause a UAS
> supporting Identity to reject the request.)
> 
> The charter of this group _*REQUIRES*_ us to "do no harm" and protect
> interoperability of current and *planned* IETF work.  The IETF already
> recommends stronger language damning the practice of body 
> modification. 
> My proposal is much more specific and implicitly allows body 
> modification
> in every case I can imagine where it is even remotely useful.  Please
> consider this when accusing me of causing an interoperability problem.
> 
> > It also references 2 IETF documents which are in draft form 
> only - which I
> > thought we were trying to avoid in this doc?
> 
> My proposed change does NOT require referencing any 
> additional documents. 
> I will however point out that Identity is approved and in the 
> RFC editor
> with no blocking dependencies.  It is likely to be published 
> before the
> SP-PBX interop spec.  As for ICE, it is a WG item and has undergone
> significant review.  The concept has been stable for nearly 
> two years and
> has significant WG and IESG support, and the only thing we 
> require from
> ICE for this document is the string "a=candidate:".
> 
> thanks,
> -rohan
> 
> 
> > Thanks,
> > Hadriel
> >
> > -------------------Rohan's change-----------------
> > Section 8
> > 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 for SIP
> > 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).
> > ---------------------end change-------------
> >
> > _____________________________________________
> > 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_PBX_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: ATT00592.txt >>
> >
> >
> > _______________________________________________
> > techwg mailing list
> > Send mail to: techwg at sipforum.org
> > Unsubscribe or edit options at:
> > http://sipforum.org/mailman/listinfo/techwg
> >
> 
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:  
> http://sipforum.org/mailman/listinfo/techwg
>