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

[Gonzalo Camarillo <[e-mail]>]

It is nicer to send complete URIs in the "to" header. If the i-gateway 
sends the INVITE before receiveing all the digits, the "to" header is
not complete. It would contain just a few digits of the whole telephone
number (this assumes that with just some digits the i-gateway figures
out where to send the INVITE).

Gonzalo

[e-mail] wrote:
> 
> >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

-- 
Gonzalo Camarillo         Phone :  [phone]
Oy L M Ericsson Ab        Mobile:  [phone]
Telecom R&D               Fax   :  [phone]
FIN-02420 Jorvas          Email :  [e-mail]
Finland