Subject: RE: TRIP

From: James Yu <[email-masked]>
Date: Tue, 28 Dec 1999 08:58:09 -0600

Overlap dialing probably happens often for international calls where the
switch in the originating country don't know much about the numbering plan
of the destination country.  The criteria to begin processing the received
digits at the originating switch may be based on the minimum number of
digits and the expiration of the inter-digit interval as have been indicated
by several people.   For a voice call to a destination Switched Circuit
Network (SCN) that involves IP,  the call can be originated from an IP phone
(e.g., SIP client, H.323 terminal) or from an SCN phone.  The IP phones may
be designed to allow en-bloc signaling.  But overlap signaling probably
cannot be avoided for the SCN-IP-SCN case.  The originating switch may not
know whether subsequent digits will be dialed.  So even if a mechanism to
carry the "overlap vs. en-bloc" signaling exists, the originating switch may
need to set it to "overlap signaling" in case it is not sure whether all
digits have been collected (e.g.., international calls).

It seems that certain proxy servers may need to be designated as the check
point when overlap signaling may be involved based on the From and To
information and others.  Hope that we can get some ideas/solutions at the
1/25-27 ITU IP & Telecoms Interworking Workshop.

James

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, December 24, 1999 4:33 PM
> To: James Yu
> Cc: John Mainwaring; Mark Foster; [email-masked];
> [email-masked]
> Subject: Re: TRIP
> 
> 
> 
> 
> James Yu wrote:
> > 
> > For overlap signaling, a GW or LS that receives a call with 
> partial address
> > information may not know that the address info. is 
> complete.  If it launches
> > a query (DNS or NPDB), the entity that has the "number 
> portability" info.
> > won't be able to find the info. because the address info. 
> is incomplete.  It
> > seems that either this LS or GW may wait a little while to 
> see whether there
> > are subsequent address info. before launching the query, or 
> it can launch a
> > query (DNS or NPDB-like), receives an error (hope that it 
> is specific such
> > as incomplete address instead of something ambiguous), and 
> then wait for
> > additional address info. before timing out.
> 
> I think Dean had sent out some pseudo-code some time back on how trip
> and enum and overlap interact, and this was more or less what the code
> suggested. I believe he thought it was a bad thing, and so do I.
> 
> Overlap dialing seems fundamentally in conflict with LNP or 
> enum queries
> at the local outbound proxy.
> 
> To do LNP, the local outbound proxy needs to have the entire string of
> digits before it can perform the query. But, overlap seems to 
> imply that
> it won't ever know the entire string of digits, as it doesn't have
> knowledge of those numbering plans. It just forwards the 
> request to some
> other proxy or gateway that does.
> 
> Sooo, it would seem that a proxy should only use enum or LNP 
> for numbers
> it knows to be complete. This means that for overlap dialing, the LNP
> query will happen close to the destination (possibly even in 
> the PSTN),
> not unlike the N-1 case we've been discussing. However, for 
> en-bloc, it
> can happen anywhere. This does seem to imply that a proxy 
> needs to know
> whether the number in the request URI of an incoming request 
> is en-bloc
> or overlap. It could make this determination if it knew the 
> structure of
> the numbering plans, but thats unlikely. Might we need a parameter
> somewhere (ugh)? I really hate to crowd SIP with things to support old
> legacy technologies like overlap, so if we can avoid this, I'd be very
> happy.
> 
> 
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120 
> dynamicsoft                                 West Orange, NJ 07052
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
>

---

From: "Vance Shipley" <[email-masked]>
Date: Tue, 28 Dec 1999 15:58:44 -0500

James Yu writes:
}
}  Overlap dialing probably happens often for international calls where the
}  switch in the originating country don't know much about the numbering plan
}  of the destination country.  The criteria to begin processing the received

Actually no.  The ITU recommendation Q.767 "Application of the ISDN user part
of CCITT Signalling System No. 7 for international ISDN interconnections" is
used today on the International Plane between countries public telephone
networks.
This recommendation defines how ISUP signaling is to be applied toward the
application of international gateway interconnections to other countries
gateways.

Q.767 does not allow for overlap signaling.  If the local serving office switch
for the originating subscriber uses overlap signaling to speed up call routing
then an intermediate switch, or the gateway switch itself, will gather up all
the digits and send the call forward enbloc.

Overlap signaling is not used in ANSI ISUP at all.  Overlap signaling was used
in the days of in band signaling to speed up the delays caused by the relatively
long duration of the tones used.  One area where it was almost always used was
in fact international calls.  In the case of FGD signaling in North America when
an international call was presented the country code was sent first using
<KP>CC<ST> so that the switch could begin route selection and grab an outgoing
route while the rest of the digits where pulsed in.  This becomes unnecessary
when ISUP signaling is used.

In my mind overlap signaling should never be generated but may have to be
supported
when received.  The receiving switch must buffer the received digits until it
decides
that all have been received and then forward the call enbloc.  There are two
methods
the switch may use to recognize when all digits have been received.  The best is
when
the switch has an accurate view of the dialing plan(s).  It would know that
country
code XX, city code YYY requires exactly 7 digits in the subscriber number and
when it
received all 12 digits it would forward the call enbloc.  If it never received
enough
digits it would eventually time out and release the call with a cause code
indicating
"address incomplete".  The second method simply applies an inter digit timer and
maximum
number of digits.  Digits are buffered until either the maximum expected are
received,
the inter digit delay timer expires or an end-of-dial digit is recognized (e.g.
<ST>
or '#').  These methods are generally both used where some dial plans are
recognized
(e.g. North American Plan) and the rest use the time out.

	-Vance