Subject: RE: draft-ietf-mmusic-sip-multipart-00.txt

From: "James McEachern" <[email-masked]>
Date: Thu, 10 Jun 1999 13:48:54 -0500

> I realise that, with the INFO extension, the subsequent messages
	> could be sent following the INVITE/IAM message; however, this
	> seems like an unnecessary amount of network overhead.

	But if you haven't received yet all the B-number, how do you know
where
	to send the INVITE?

Wouldn't you do this the same way that existing PSTN switches do it.  (i.e.
collect digits until you can identify the destination "switch" - or MGC -
then send an IAM, followed by SAMs for each additional digit.)  With an open
numbering plan, only the terminating switch really knows for sure when the
number is complete.  The use of timers to reduce SIP messages will result in
inferior service to the 80% of the worlds population served by open
numbering plans - which does not sound like a good thing to me.

The more interesting question is what should the interaction be between the
"ISUP call model" and the SIP UA in deciding where to send the SIP invites?
For example, who is responsible for locating the terminating MGC (assuming
in this case that the destination is in the PSTN)?  Does the answer depend
on whether the originator is a PSTN terminal or a SIP UA? 

	You could send it to a SIP proxy, but the proxy would have to wait
for
	the SAMs anyway to reach the proper user... and it would mean that
the
	SIP proxy understands ISUP (and we do not want this to happen,
right? ).

	You could also send it to a MGC that will end up in the PSTN network
	again, but how do you know which MGC you have to send it to?

	Gonzalo
	-- 
	Gonzalo Camarillo         Phone :  +358  9 299 33 71
	Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
	Telecom R&D               Fax   :  +358  9 299 31 18
	FIN-02420 Jorvas          Email :  [email-masked]
	Finland

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 10 Jun 1999 18:11:31 -0500 (CDT)

>on whether the originator is a PSTN terminal or a SIP UA? 

This can be heavily dependant on the individual implementations
of network nodes without bothering to standardise where the
information "should" be located. That's the elegance of the
SIP protocol.

One simple solution for PSTN/SIP gateways would be for each
gateway to have a map of which number prefixes should be
sent to which destination; e.g.:

number map | destination
-----------+------------------------------------
1713*      | pstn-gw.houston.tx.us.bell.com
1218*      | pstn-gw.bemidji.mn.us.bell.com
46054*     | pstn-gw.karlstad.ks.se.bell.com
44*        | sip-proxy.bt.co.uk
1972583*   | pbx-gw.ericy.com
1800555*   | sip-redir.800.bell.com
1500555*   | sip-redir.sip-clients.bell.com
default    | bell.com

This allows the gateway owner to either specify which egress
gateway (as in the case of the Houston, Bemidji, and Karlstad
entries), a proxy server into another vendor's network
(as in the case of the 44* entry), private exchange gateways
(like the ericy entry), a redirect server for PSTN calls (like
the 800 server), and a redirect server (and probably
registrar) for native sip clients, as in the 1-500 entry.
I'll describe what I'm thinking of with the default entry
in a bit.

If a particular service provider wishes to encapsulate all
of the routing into a centralised database, they can have
just a single "default" entry which points to a proxy or 
redirect server in charge of determining a final destination.

For standard (e.g. PC-based) SIP UAs, you could have a similar
(more complete, if necessary) routing table in a redirect or
proxy server which the users are then instructed
to use. This database would probably also be used as
an authoritative routing table, to which the gateways
could "punt" in case their local routing configuration data
was insufficient.

So, for the examples I have given so far, a native SIP
client, in order to place a PSTN call to +1 214 555 1212 
which is carried and billed by bell.com would use 
"sip:[email-masked]" (which would proxy or redirect them
to "sip:[email-masked]"); if the user
wanted to use xyz.com, they would instead enter 
"sip:[email-masked]" (which would proxy or redirect them
to "sip:[email-masked]").

To reiterate: the answer to your question is "whatever the
service providers decide they want to do," since any solution
will be compatible with any other arbitrary solution (although
I think the basic architecure I described above has a certain
elegance).

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 11 Jun 1999 10:37:36 +0300

Hi,

> >on whether the originator is a PSTN terminal or a SIP UA?

The terminating MGC should not depend on the originator... it depends on
the carrier you want to use (sip:[email-masked] or
sip:[email-masked]).
 
> entries)

Yes, this way we can send the INVITE to the proper destination. But if
this is a PSTN/SIP gateway in the States, and we end up in Karlstad
(Sweden), which flavour of ISUP will we send in the SIP body?

We could send a "Require" header in the SIP request indicating that we
are sending ANSI ISUP.
We could answer with an "unsupported" header, since they do not want to
receive ANSI ISUP in Sweden... then, the MGC in the States would send
ITU ISUP, or whatever is understood in Karlstad...

How do you guys think this negotiation has to take place?

Regards,

Gonzalo

>, a proxy server into another vendor's network

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 11 Jun 1999 10:56:00 -0500 (CDT)

Gonzalo Camarillo 
>sip:[email-masked]).

In the case of a native SIP terminal, this makes sense. For PSTN
service, you will not typically use an egress gateway owned by
someone other than the ingress gateway, just as I don't currently
have my long distance calls carried half the way by MCI Worldcom, and
the other half of the way by Sprint. 

>(Sweden), which flavour of ISUP will we send in the SIP body?

The simple answer would be, "none." The Karlstad gateway is already
going to have the capability of creating ISUP messages to allow
native SIP clients to place outgoing calls. 

If transit of ISUP parameters is important for out applications,
and we know how to perform the translations, we could transit 
International ISUP, ITU ISUP, or a local variant of ISUP.

>How do you guys think this negotiation has to take place?

For the above cases, since we're already provisioning information
about the gateways, it could quite easily be part of the same
table (this table assumes we have a super fantastic gateway
that can do arbitrary signalling translations):

number map | destination                        | signalling   | public key
-----------+------------------------------------+--------------+-------------
1713*      | pstn-gw.houston.tx.us.bell.com     | ANSI ISUP    | A246FD87...
1218*      | pstn-gw.bemidji.mn.us.bell.com     | ANSI ISUP    | D6438E75...
46054*     | pstn-gw.karlstad.ks.se.bell.com    | ITU ISUP     | 938EF64A...
322*       | pstn-gw.brussels.be.bell.com       | Belgian ISUP | 3E71F29E...
44*        | sip-proxy.bt.co.uk                 | BT NUP       | 375D17FA...
1972583*   | pbx-gw.ericy.com                   | NONE         | -
1800555*   | sip-redir.800.bell.com             | ANSI ISUP    | E93F2A7E...
1500555*   | sip-redir.sip-clients.bell.com     | NONE         | -
default    | bell.com                           | NONE         | -

Because of regulations in some countries, we will always need to
have the option of blocking ISUP transit to selected destinations;
starting out with the assumption that we can just go ahead and
send out the local varient to see if it gets rejected may land 
operators in legal problems.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Jun 1999 22:22:56 -0400

> the other half of the way by Sprint.

Well, you do have separate local carriers and long distance carriers.
So, in the PSTN, your call is often carried by three different providers
along the way (two locals, one on each end, and a long distance
provider). Possibly more for international calls.

I think its highly unlikely that the same organization that owns the
ingress gateway will always own the egress. For international calls in
particular, you cannot expect them both to be by the same provider.
Rather, I would expect inter-provider relationships to be established to
share gateways amongst each other. This is already happening with
clearinghouses like ITXC.

In fact, this is the reason for the Gateway Location Protocol in iptel -
to allow providers to exchange gateway routing information.

> number map | destination                        | signalling   | public key

It seems unlikely that a provider will be able to build up a table of
every single gateway in every single remote provider which might be
contacted. Rather, a provider might know that calls for +44 get routed
to a particular SIP server, and from there the calls are distributed to
specific gateways. What I am talking about is aggregation - the table
above would really contain "next hops", not destination gateways. This
kind of aggregation has been the cornerstone of inter-domain routing
mechanisms on the Internet.

This fact only makes the ISUP-flavor problem worse. I believe the ideal
solution is to agree on a common flavor for the Internet. Think of the
Internet as another "country" with a speific flavor. When you talk to a
gateway in this pseudo-country, you convert to its flavor just as you
might need to do at other international boundaries. Whether this is
politically or economically feasible is a good question that I don't
know the answer to.

If we presume that we don't generally know the terminating UAS for every
phone number, its possible that the request terminates at a regular IP
host, like a standalone IP phone or a PC. In this case, sending it ISUP
is probably not a good idea. But how would you know in the first place?

In a closed, singly owned administrative authority, it is certainly
feasible to know the actual gateway that would terminate each call, and
what flavor it speaks. However, if they are all owned by the same
authority, they are all likely to speak the same ISUP flavor anyway...

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 14 Jun 1999 14:14:34 +0300

Hi,

> > number map | destination                        | signalling   | public key

Well, that's true, but if you are using IP telephony, how are you going
to know if an IP address is in one of those selected destinations?

So, if using gateways the PSTN network and the IP telephony network are
going to merge, some of these features/services will not make sense any
more.

> mechanisms on the Internet.

OK, my idea was that SIGTRAN was useful when there were two huge
gateways sending messages between them (PSTN-IP-PSTN).
SIP had to be used when we contact a SIP server, that can provide lots
of services... the problem appeared when that SIP server could re-direct
the call to PSTN again... then, we have to encapsulate ISUP in the
message body of the SIP message.

But if in the ingress gateway we know that the next hope is a signalling
gateway that ends up in PSTN again... why don't we use SIGTRAN?

> politically or economically feasible is a good question that I don't

Well, we have already the International ISUP as a common flavour between
different PSTN networks placed in different countries...
The problem is that International ISUP does not support many services...
so, the basic call will go through, but all the fancy features of the
national ISUPs are lost.

If a service provider cannot provide services when the call goes over
IP, how are they going to make money. The user wants services.

> is probably not a good idea. But how would you know in the first place?

If you send an ISUP body to a SIP phone, it can just discard it ( we
have used some extra bandwidth though).
If you don't send the ISUP information to the egress gateway, it will
lose a lot of useful information for building its outgoing ISUP
messages.

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 14 Jun 1999 12:33:34 -0500 (CDT)

>provider). Possibly more for international calls.

This model makes no sense in the context of IP telephony. Yes, we can
talk about who owns the cables and the routers; but, at a protocol
level, it doesn't make sense.

>particular, you cannot expect them both to be by the same provider.

Not always, which is why I've structured the table the way that I did.

>mechanisms on the Internet.

Precisely. That's the point of the 44* example I gave. You put in
the information that you either have control over or have negotiated
in interconnect agreements. In the other situations, our theoretical
bell.com guys actually have a presence in Houston, Bemidji, Brussels,
and Karlstad. But, just like you maintain your own DNS information
within your organization, you will maintain your own gateway routing
information.

>politically or economically feasible is a good question that I don't

You *could* form a superset of all the currently existing ISUPs. 
The problem is that, no matter how comprehensive you make it *now*,
it will need revision whenever a new ISUP varient is defined or
an existing ISUP varient is expanded. I don't beleive any standards
body would be willing to take on this task.

I believe it is more likely that your interconnect agreements 
would define what flavor of ISUP each authority is expecting. We'll 
take the 44* example from my table above, again. In this circumstance, 
bell.com's agreement with BT indicates that bell.com is to send
and receive BT NUP; it is bell.com's responsibility to provide
the signalling translation. This is not to imply that all of the
destinations on the other side of BT's SIP proxy will necessarily
speak BT NUP. The BT proxy may, in fact, choose to translate
incoming messages to British ISUP before sending it to a
particular gateway, if their proxy's table so indicates.

number map | destination                        | signalling   | public key
-----------+------------------------------------+--------------+-------------
1*         | sip-proxy.bell.com                 | BT NUP       | 7AE82310...
44161*     | manchester.bt.co.uk                | BT NUP       | 739118DC...
44131*     | edinburgh.bt.co.uk                 | British ISUP | DEA042BC...
44141*     | glasgow.bt.co.uk                   | BT NUP       | C7A070BC...

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jun 1999 21:52:12 -0400

> level, it doesn't make sense.

I believe it does. For pure IP, there are backbone providers and access
providers. There are protocols between them (BGP) for exchanging and
accepting of routes, based on policy. Your packet from A to B thus
traverses the set of ISP's who have agreements along this path. For IP
telephony, GLP works in a similar way. A provider would make its
gateways available to others, who would in turn (based on policy)
aggregate this information and make that available to others, and so on.
The signaling, as a result, may pass through these providers on the way
to the gateway (this is a difference between GLP and BGP, since in GLP,
the signaling can bypass location servers). You might want to have a
look at the GLP framework document (now in wg last call, so if you have
comments, we'd love to hear them..) at:

http://www.bell-labs.com/mailing-lists/iptel/draft-ietf-iptel-gwloc-framework-03.txt

> particular gateway, if their proxy's table so indicates.

This is one possibility, and closely aligns (I think) with how its done
in the traditional telephone world. But, it has the horrible side effect
of requiring proxies to not only parse the payloads of SIP messages, but
translate them as well. One of the very attractive aspects of the SIP
model is this proxy-payload transparency. We can use the same SIP
servers to invite people to multimedia sessions and interactive games,
since the session stuff is all in the payload. 

-Jonathan R.

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 15 Jun 1999 10:13:11 -0500 (CDT)

>translate them as well.

Be careful how you phrase that: it requires **SOME** very specific
proxies which are used to enforce policy to occasionally translate
or remove ISUP payloads. This is not a general proxy requirement.

If anyone is transiting ISUP across the network in SIP messages,
there will *have* to be nodes which understand who is allowed
to receive ISUP messages. As you've said, the gateways can't
reasonably be expected to have sufficient information to know
whether ISUP is acceptable for each outgoing call, so the nodes 
that *do* know need to be in the middle of the call somewhere. You 
can call these enforcement nodes whatever you want, but they're 
proxies at heart.