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

["Tom-PT Taylor" <[e-mail]>]

The SAM solution works if sending ISUP in SIP works.  The basic principle is
this: if too few digits are available at a given stage to locate an egress
gateway, a 484 final response is sent back to the ingress gateway saying so.
The ingress gateway has to wait for more digits, then reissue the INVITE
(with updated encapsulated IAM).  Eventually either the call is found to
terminate on a non-ISUP network (in which case there has to be interworking
somewhere along the signalling path) or it terminates on an egress gateway.
In either case the ingress gateway will forward SAMs via INFO messages to
the point where they are consumed.  (The obvious exception is if the ingress
gateway itself is the point at which interworking must occur.)

> -----Original Message-----
> From:	Adam B. Roach [SMTP:[e-mail]]
> Sent:	Tuesday, November 16, 1999 6:06 PM
	[[TomT]]  ... >
> >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
>