[SIPForum-techwg] IP PBX / SP Interop Draft Version 5proposededits (round two)
Chris Sibley
Chris.Sibley at cbeyond.net
Wed Mar 8 11:02:52 EST 2006
Hi Sofia,
I agree with your comment "The consequences of not supporting it - is
not just a IP PBX/SIP Interop issue, it affects SP interworking with
PSTN in general."
If the mapping between SIP/ISUP is not defined / implemented in
accordance with some common "standard", then interworking with the PSTN
in general will be broken. Since this specification's primary purpose is
to enable reliable PSTN origination / termination via SIP, I personally
believe that RFC 3398 plays an important role in the specification.
Mandating support for RFC 3398 will also provide the Enterprise (and SP)
guidance on call flows, error handling, etc. IMO, a good portion of this
should be verifiable/observable from the standpoint of a party watching
SIP packets coming into / leaving their network...
Thanks!
---Chris
_____
From: Nekrasovskaia, Sofia (Com US)
[mailto:sofia.nekrasovskaia at siemens.com]
Sent: Wednesday, March 08, 2006 9:39 AM
To: Horvath, Ernst; Chris Sibley; SIP Forum Tech WG
Subject: RE: [SIPForum-techwg] IP PBX / SP Interop Draft Version
5proposededits (round two)
Chris,
I am not a team member (so you may disregard my comment :>)) but I agree
with Ernst, it's not relevant to the spec. One of the internal
components of Service Provider's network must support the ISUP/SIP
mapping if communicating to both SIP and ISUP domains, this is already
described in related standards (not just RFC3398).The consequences of
not supporting it - is not just a IP PBX/SIP Interop issue, it affects
SP interworking with PSTN in general.
Regards, Sofia
_____
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Horvath, Ernst
Sent: Wednesday, March 08, 2006 6:59 AM
To: Chris Sibley; SIP Forum Tech WG
Subject: RE: [SIPForum-techwg] IP PBX / SP Interop Draft Version
5proposededits (round two)
Chris,
ad item Standards Support (part four):
from an enterprise point of view, I don't really mind if you keep ISUP
mapping in the spec, it is just not relevant for the interface between
enterprise and service provider.
My reasons for suggesting to remove it were:
* The signaling gateway is an internal element of the Service
Provider domain, its communication with the SAS is ouside the scope of
this specification (see section 4 and the architecture diagram - the SG
is not linked to any other device)
* The mapping is not visible and testable at the enterprise
domain.
* Even the mapping were visible, enterprise networks usually have
no notion of ISUP (they "speak" QSIG, DSS1,...).
* RFC 3398 is one mapping standard, but there are other equivalent
ones from ITU-T and national standardisation bodies.
Thanks,
Ernst
_____
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Chris Sibley
Sent: Tuesday, March 07, 2006 7:29 PM
To: SIP Forum Tech WG
Subject: [SIPForum-techwg] IP PBX / SP Interop Draft Version 5
proposededits (round two)
Importance: High
IP PBX / SP Interop WG team members,
Following is a compiled list of comments related to various
standards-support issues which was derived from the "master list" of
2/27 - 3/2 comments. Please give them a quick read and respond with your
vote and/or any additional comments.
After we get these discussion points nailed down, I will send out one
last round of minor issues that require consensus / additional
discussion.
Thanks!
--Chris
-------------------------------------------------
Standards Support (part one)
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.)
Editor's Comments:
[NOTE: Per earlier discussion/voting, RFC 3265 and 3892 have already
been removed so this discussion should be limited to the remaining three
RFCs highlighted above.]
RFC 3515 (The Session Initiation Protocol (SIP) Refer Method) - Since we
have already decided to not include RFC 3265 in the specification, I
agree that it doesn't make sense to include 3515 (due to the fact that
3515 utilizes the event notification functionality outlined by 3265.)
RFC 3842 (Message Summary and Message Waiting Indication Event Package
for the Session Initiation Protocol (SIP) - Since we have already
decided to not include RFC 3265 in the specification, I agree that it
doesn't make sense to include 3842 (due to the fact that 3842 utilizes
the event notification functionality outlined by 3265.)
RFC 3891 (The Session Initiation Protocol (SIP) "Replaces" Header) - I
agree that there are currently no use cases for this particular
functionality in the specification.
Recommended Disposition: Remove RFC 3515, 3842, and 3891 support from
the specification.
------------------------------------------------------------------------
------------------------------
Standards Support (part two)
Hadriel Kaplan wrote:
"And Rec. E.164 should not be "M" for PBX or SPS - it should be "-"."
Editor's Comments:
The PBX is required in many places throughout the specification to
populate various header fields using E.164 addresses, so I would argue
that this does imply the need to "support" E.164. However, you might
argue that the SPS doesn't need to understand anything about E.164
addresses (since it should only require analysis of the host portion of
URIs to perform its job).
Recommended Disposition: Remove Rec. E.164 support for the SPS (only).
------------------------------------------------------------------------
------------------------------
Standards Support (part three)
Hadriel Kaplan wrote:
"And RFC 3824 should not be "M" for SPS, and probably not for SAS or PBX
either since you do not mandate ENUM."
Editor's Comments:
Agreed, nowhere in the specification do we explicitly require the use of
ENUM. And since RFC 3824 assumes the use of ENUM, it is probably not
needed.
Recommended Disposition: Remove RFC 3824 support from the specification.
------------------------------------------------------------------------
------------------------------
Standards Support (part four)
Ernst Horvath wrote:
"- Section 15.2. Mapping to/from ISUP should be outside the scope of
this specification."
Editor's Comments:
I disagree. I think it is very important for the service provider and
(particularly) equipment manufacturers to have a clear, verifiable
reference of SIP <--> ISUP mapping rules. RFC 3398 defines various call
flows, rules for mapping ISUP field values to SIP header field values,
etc. This information should prove to be very useful guidance to any
equipment manufacturer building a device that is compliant with this
specification.
Recommended Disposition: Keep RFC 3398 support in the specification (no
change).
------------------------------------------------------------------------
------------------------------
Standards Support (part five)
Rohan Mahy wrote:
"- requirement for the early-session disposition
This recommendation is well motivated by the text. However, can we
identify two interoperable implementations of the early-session
disposition? If not, we will need to remove it."
Editor's Comments:
Agreed. In general, while I think RFC 3959/3960 support will prove to be
very useful (in the future, once more UAs implement it) it is probably
also true that we are a little ahead of the game in recommending that it
be used now.
Recommended Disposition: Remove RFC 3959/3960 support 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 3:24 PM
To: SIP Forum Tech WG
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
<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
_____
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
_____
**********************************************************************
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/6d1b26cf/attachment.html
More information about the techwg
mailing list