[SIPForum-techwg] SIPconnect 1.1 comments

[Michael Lunsford]

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).



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