[SIPForum-techwg] Cbeyond SIPconnect 1.1 Comments

[Marc Robins]

Comments re: SIPconnect 1.1 sent out on behalf of Michael Lunsford at
Cbeyond

------ Forwarded Message
From: Michael Lunsford <michael.lunsford at cbeyond.net>
Date: Tue, 23 Sep 2008 09:57:21 -0400
To: <techwg at sipforum.org>
Conversation: SIPconnect 1.1 comments
Subject: SIPconnect 1.1 comments

4.1.2 Obtaining Service Provider Network Address We suggest that it be
explicitly stated that the location of the Service Provider's SIP Proxy
Server be based on a Fully Qualified Domain Name and not be provisionable
with an IP address. Configuration of an IP address lends itself to
substantial reconfiguration efforts if renumbering of IP space were ever
required.  We have also observed some poor PBX behavior where DNS TTLs were
not honored. Would this be considered within the scope of this document?

7 Firewall and NAT Traversal
This section does not meet the objective of making a PBX interoperable with
a SP by virtue of both being SIPconnect 1.1 compliant. The first paragraph
provides an exception of publicly routable IPs in the SDP if SP is providing
a Hosted NAT Traversal function.

8.1 Registration Failures
I would suggest that all of the backoff timers mentioned in this section
have a maximum back of time of around 900 seconds. This interval is
sufficient to prevent inadvertent "DoS-like" behavior. A SP implementing the
registration model for locating enterprises would be significantly affected
during a scenario where a 401 / 404 / 407 was returned erroneously during a
maintenance window or server failure condition.

10.1 Authentication of the Enterprise by the Service Provider Cbeyond would
also like the change to make TLS mutual auth a MAY for the SAS and Digest
auth a MUST.  TLS authentication will most likely be implemented by an SPS
in the SP network and not the SAS. The SAS is most likely the device
implementing Accounting. Not having authenticated the user, the SAS can't
credibly bill the appropriate user for the call. This would also require a
change in the PBX support to MUST support Option2, Digest Auth.

15.6 Controlling the Calling Line ID and Calling Name Presentation There are
no specific requirements called out of the SIP Application Server which MUST
be required to support if the SP is required to support.

17.5 Retargeting Related Services
The impact of retargeting of requests on SP session limits for the IP PBX
should be considered for mentioning. As described in 17.3.2 Session Limits,
the SP typically limits the number of active sessions an Enterprise may use.
Retargeting a request with a 302 or REFER may reduce the number of sessions
used on the interface in many cases depending on the SAS implementation. As
an example, a call from the PSTN to an auto attendant which directs the call
to an extension and is forwarded back of to the PSTN would consume 2
sessions on the Enterprise - SP interface if the PBX bridges the call but
may consume no sessions if the PBX used a REFER w/ Replaces to transfer the
call (this, of course, is implementation dependent on the SAS).

------ End of Forwarded Message

------ End of Forwarded Message


**********************************************************************
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
**********************************************************************