[Sipping] Comments on draft-roach-sipping-callcomp-bfcp-00

I have the following concerns:

1. Implementation costs and performance. The earlier Poetzle proposal was a
SIP solution, whereas this is a media solution, where BFCP is carried over a
TCP connection negotiated by offer-answer exchange. I see this new proposal
as requiring significantly higher implementation costs and giving rise to
potential performance issues. Consider a gateway, for example. For each call
completion request in progress, it needs to maintain a TCP connection
associated with the SIP INVITE-initiated dialog and with the corresponding
PSTN signalling association. This involves occupation of resources such as
ports, memory and processing resources for keep-alive etc. During
establishment and tear down it requires extra processing resources and extra
signalling, including ICE for NAT traversal. This could have a significant
impact on the scalability of gateways. Furthermore it might not fit too well
into distributed gateway architectures. Although I cite gateways as a
particular example, it will have similar impact on other devices such as
phones, B2BUAs and Application Servers.

2. Flexibility in choice of gateway. I understand that the earlier Poetzle
proposal does not constrain an INVITE request (for call completion) to pass
through the same PSTN gateway as that which acts as notifier for the event
package. For an incoming request from PSTN to SIP, I am not sure whether the
PSTN call request will necessarily arrive at the same gateway to SIP as the
original call completion request. With QSIG there is nothing to constrain it
to arrive at the same gateway, since routing is only on the basis of the
called party number, which equates to the SIP AoR of the callee. I can't
remember whether this is true also for ISUP or Q.93x. This could be a
concern with the Roach proposal, because if you don't hit the right gateway
you will not be able to pick up the contact URI to get you to the entity
that acts as the floor control server. This might not matter if a single
application server or B2BUA acts on behalf of the callee (so that the AoR of
the callee is sufficient to get there), but it certainly won't work if one
of several registered contacts for that AoR acts as the floor control
server.

I am not so convinced that the earlier Poetzle proposal was such a bad idea.
Although it perhaps doesn't fit with the original semantics of SUBSCRIBE, it
doesn't seem to do any harm. In fact I don't think it is 100 miles away from
the proposed use in draft-ietf-sipping-policy-package, particularly if the
policy server reserves resources as a result of the subscription request.

John