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

From: [email-masked]
Date: Mon, 22 Nov 1999 15:13:26 +0200

Dear Matt,

Some comments regarding your article below:

> 	I agree with every thing you have detailed except for
> the statement extracted below.  I agree the problem is 
> getting smaller and smaller since it really is a hold 
> over from pre-SS7 days. My question is why do we need 
> to provide backwards compatibility? Mobile seems to have
> done a very good job of not providing this.
> Why not take the same approach as mobile and exclude support?
> 
> IMHO this is one legacy PSTN function that needs left on the PSTN.
> The amount of work required to support the feature is just
> not justified.
> 
> Matt
 
The key issue here is that the mobile networks needn't to support 
overlap sending, because the mobile phones provide a way to use enbloc 
sending, but the analogue POTS phones don't.

This is the reason for which you have to have an element in the PSTN, 
where you switch from overlap sending to enbloc sending. 
This place has to be the same one, where you have the 
number analysis tree, usually a class 5 switch. 
This devices waits for the digits, one by one, and determines 
the next hop as soon as the matching prefix is found (if there are 
several overlapping prefixes, there might be some policies involved).

Think now about the case of a VoIP access gateway or a call agent. 
If SIP wouldn't support overlap sending (which by the way is easily 
done with a help of sequential INVITEs and 484's as Jonathan R. 
earlier described in this list) every access gateway and call agent 
should have a number analysis tree associated with it. This results 
in a major problems in updating these trees. Basically it means that 
each of the gateways/call agents would have to take part in TRIP. 
To demonstrate the severity of the problem,consider the current PSTN, 
where there are tens of thousands of subscribers using one number 
analysis tree. How many subscribers there would be attached to one 
access gateway? Only small fraction of this I would assume.

An alternative approach would be that the number analysis tree is 
only located in one centralized server, which updates it using TRIP, 
and the access gateways/call agents use SIP towards it in overlap 
sending fashion, as described by Jonathan.

Now I see another problem. What if the default SIP server detects 
(by using TRIP or enum for example) that there is no SIP URL 
associated with the dialed number, but only a H.323 gatekeeper? 

The SIP RFC mentions that some kind of a "H.323 URL" should be 
included in the resulting REDIRECT message, but has this been 
addressed by anyone? At least I couldn't find any information at 
all about this. I would be happy, if somebody bothered to prove me 
wrong.

Regards,

Mikko Alutoin
Nokia Networks
[email-masked]

---

From: "Matt Cannon" <[email-masked]>
Date: Mon, 22 Nov 1999 09:06:04 -0600

Mikko, thanks for the comments.

Mine are line preceded by MJC==>

Matt

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Monday, November 22, 1999 7:13 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt
> 
> 
> Dear Matt,
> 
MJC==> Agreed, but why does it need to find the next hop? If it
uses Gonzalos timer method/# and then routes, it also works.

> access gateway? Only small fraction of this I would assume.
MJC==> You answer this in the next line. Don't do it if you can
avoid it.

> sending fashion, as described by Jonathan.

MJC==> And the difference again comes down to, do I collect all the 
digits first or start querying with partial strings. My answer
stays the same collect all the digits first.

> associated with the dialed number, but only a H.323 gatekeeper? 

MJC==> This is routing question not a SAM question.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Nov 1999 15:04:15 -0500

> access gateway? Only small fraction of this I would assume.

The problem of where to put the routing function (gateway, proxy), and
how much data is in it, seem completely orthogonal to the issue of
overlap vs en-bloc. In fact, with the suggestion to use INVITE with
cumulative digits, the whole idea was that a proxy with a routing table
wouldn't even know that overlap dialing was taking place.

> associated with the dialed number, but only a H.323 gatekeeper?

Again, orthogonal issue. Locate a gateway and send it there. TRIP
supports things like this, FWIW.

> all about this. I would be happy, if somebody bothered to prove me

My understanding (Pete can correct me) is that there is no currently
specified H.323 URL. In any case, that is also a separate issue. There
is no need to have redirects in this case. The SIP could be proxied to a
signaling conversion gateway that converts SIP to H.323.

-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