Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

["Adam B. Roach" <[e-mail]>]

>The use of a timer to force enbloc signaling is not acceptable. In the case
>of SIP bridging, subscribers originating calls from the PSTN will not accept
>an artificial post-dial delay (even if it is just a few seconds long).
>Overlap signaling must be supported. It is essential that the overlap
>process takes place within the context of a single session - using the
>suggested INVITE/CANCEL/INVITE approach would result in multiple abortive
>calls being delivered to the terminating agent, which would not be
>acceptable.
>
>Why not send an INVITE message when the ISUP IAM is received and then send
>subsequent INFO messages for each ISUP SAM? I understand that "pure" SIP
>agents will expect the INVITE to contain the complete address of the called
>party. This could be handled by including support for overlap in the
>"Require" extensions (draft-roach-mmusic-sip-pstn-require-header-00.txt). If
>the terminator did not support the PSTN extensions, the originator could
>then switch to enbloc and wait for the full address to be collected.

There are a variety of problems here. The first is determining how
intervening proxies will react. If, for example, a proxy is making
decisions about where to forward messages based on a called party URI, 
your suggestion would require it to understand ISUP (for interpretation 
of SAM message). It also requires it to have number analysis code and 
dialing plan information (potentially for the entire globe).

The problem gets even stranger for redirect servers, which expect to
be able to send an immediate response to an INVITE -- not sit around
collecting digits.

Basically, your suggestion forces overlapped dialing deep into each 
and every SIP node in the network that is expected to receive calls 
originating from the PSTN network.

I agree that this is a problem that needs to be solved if we intend
to use SIP between two PSTN phones; but we need to find a better
solution than tunelling SAMs all over the place.

We shouldn't overlook human factors: it could be that customers are
willing to, for example, be trained to press "#" at the end of a
phone number to skip the post-dial-delay.

--
Adam Roach, Ericsson Inc. |  Ph: [phone] | 1010 E. Arapaho, MS L-04
[e-mail]   | Fax: [phone] | Richardson, TX 75081 USA