Subject: RE: [IPTEL] draft meeting minutes

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 2 Jan 2002 16:13:40 -0500

Please see comments inline [RRR]

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Sunday, December 30, 2001 11:53 PM
To: Roy, Radhika R, ALCTA
Cc: iptel
Subject: Re: [IPTEL] draft meeting minutes

Roy, Radhika R, ALCTA wrote:

> Comments inline [RRR]

>>The GW registration scenarios MUST not exclude any types of GWs. That
>>is, we must NOT develop the SIP-ISUP GW registration protocol per se.
>>
> 
> 
> Radhika, this has been discussed on the list, and there was a consensus 
> hum taken on this subject at IETF 52. The consensus was that non-PSTN 
> gateways are OUT OF SCOPE.
> 
> [RRR] I would appreciate if the technical reasons would have been
> documented. (I have not seen in the meeting minutes.)

Its an issue of scope and what problem people agree we are trying to 
solve. The problem we were chartered to solve, and the problem people 
want to solve, is managing the resources of a set of PSTN gateways 
fronted by a proxy. Thus, this is the problem that will drive 
requirements for the protocol.

[RRR] Good that you have provided the technical points. Let me understand your points while you are defining the scope of the "registration protocol." Is there any document that we can look into because, now, you are saying that the managing of resources of the PSTN GW resources ONLY (not the other GWs although the title of your contribution says that the GW registration protocol)?

[RRR] If there is an agreed upon written document of the scope, we would not spend time in debating the scope of the " GW registration protocol."

> Now, it may be that the protocol that is 
> developed will work for them anyway, 
> 
> [RRR] Could you please clarify this? Do you mean that the registration
> protocol can be used/extended for any types of GWs?

No, I am saying exactly what it says above. The protocol will be driven 
by requirements to handle the case where a proxy fronts a set of PSTN 
gateways whose resources it wishes to manage. If, when we are done, it 
turns out that such a protocol can in fact be used for something that is 
not a PSTN gateway, well thats fine. But it doesn't drive requirements.

[RRR] Let us add to clarify this more. It is rather SIP-ISUP GW from protocol point of view. The attributes like address family, capacity, QOS, etc. that are abstracted from the ISUP side, people call it as "PSTN" GW attributes (PSTN GW is a wrong term - an MGC/MG would have better because it is an application layer entity). In the SIP side, we are assuming that the SIP proxy and the LS are collocated, and the attributes (e.g., address family, capacity, QOS, etc) that abstracted from the SIP side are communicated via the LS.

[RRR] In the same token, we also call SIP-H.323 GW. We are NOT talking about the protocol conversion per se. Like SIP-ISUP GW, we are also talking about the attributes of the GW from the SIP side as well as from the H.323 side. For example, address family, capacity, QOS, etc. are considered for the SIP-H.323 GW registration as well.

[RRR] We hope that these clarifications will help to remove some mis-conceptions. So, we can now consider all kinds of GWs in the same baseline including SIP-ISUP, SIP-H.323, etc.

> 
> but we are not considering 
> requirements to deal with SIP-H.323 gateways.
> 
> [RRR] What are the additional requirements for the SIP-H.323 GWs that
> the registration protocol will not work?

You have asked for things like address families that are in the form of 
domain names. We will not consider that as a requirement. In any case, I 
don't think it makes any sense at all, since if you know the domain 
name, sounds like DNS is what you want. 

[RRR] The address families can include like E.164, email IDs, URL IDs, etc (as it has been done in H.323/H.225.0 Annex G). DNS may not be involved directly as it can be seen in the case of H.323/H.225.0 Annex G.

I fought against the inclusion 
of domain-name based address families in TRIP in the first place for the 
same reasons.

[RRR] It is a good news that you fought for something that is needed in TRIP where E.164 address families have been addressed. You might have also fought NOT to include the SIP-ISUP (PSTN) GW capacity, QOS, and other attributes that are very very complex to propagate among the LSs in the inter-Domain environment. You did all the right things for TRIP and I agree with you.

[RRR] However, the above things do NOT need to be true for the GW registration protocol. A GW registers all its attributes including address families (E.164, email IDs, URL IDs, etc.), capacity, QOS, and others. How all these attributes will be propagated among the LSs either in the intra-Domain or in the inter-Domain is a separate issue. For example, TRIP allows to propagate only the E.164 address family among the LSs in inter-Domain environment, NOT the email IDs, URL IDs, capacity, QOS, or other attributes.

[RRR] Now we can examine how other protocols have been developed in solving the above problem. For example, H.323 allows that a GW will be able to register all kinds of address families (e.g., E.164, email IDs, URL IDs, etc.), capacity, etc. H.323/H.225.0 allows how all these address families (e.g., E.164, email IDs, URL IDs, etc.) can be communicated among the GKs using the LRQ/LCF/LRJ messages in intra-Domain environment. And a complete H.323/H.225.0 Annex G protocol suit has been developed to transfer all these addresses (e.g., E.164, email IDs, URL IDs, etc.) among the GKs/BEs in inter-Domain environment along with other attributes.

[RRR] So, our point has been that if we develop the GW registration protocol that registers all the attributes of a SIP-ISUP (PSTN) GW, we do not need to develop any NEW protocol to register the attributes of the SIP-H.323 GW from the SIP side (H.323 side is already taken care of by the H.323 protocol suits). For example, the GW registration protocol will have a field for address family and the same field can be used to register all addresses (e.g., E.164, email IDs, URL IDs, etc.) as desired. The thing that we need to take care of is that TRIP or I-TRIP will use ONLY the E.164 addresses (not email IDs, or URL IDs) among the LSs for propagation of routes. It is NOT a rocket science.

> [RRR] I am assuming that we will develop the registration protocol
> considering the SIP-ISUP GW first while the protocol can be extended for
> other GWs as well.

You are fixated on protocol conversions. That is not the problem at hand.

[RRR] We are NOT talking about the protocol conversion like SIP-ISUP or SIP-H.323 as explained above. We are ONLY interested about the attributes (e.g., address family, capacity, QOS, etc) of the GW that is seen from the SIP proxy/LS side. We are NOT concerned about the ISUP or H.323 or SIP protocol per se. So, there is no reason that you should be concerned with.

The type of SS7 protocol is not the primary point; 

[RRR] Agreed as clarified above.

the primary 
point is that these are PSTN gateways, possibly large ones, with 
attributes that reflect the fact that there is PSTN connectivity. That 
means its things like ASR and PDD that need to be conveyed.

[RRR] As I mentioned before, we are developing the GW registration protocol that will have the fields like address family, capacity, QOS, and others to satisfy the needs of the SIP-ISUP [PSTN] GW first. Once we do this, the same fields can also be used to satisfy the needs of the registration for other GWs like SIP-H.323 GW by default. We do NOT need to do any extra work. Let us keep our mind OPEN, because we are developing the GW registration protocol (not the TRIP [inter-Domain] or I-TRIP [intra-Domain] that works among the LSs ONLY for the E.164 address family).

[RRR] The main thrust of our argument is that the same GW registration protocol that will be used to satisfy the needs of the SIP-ISUP [PSTN] GW will also be applicable to register the SIP-H.323 GW as explained above.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 02 Jan 2002 19:40:36 -0500

Jon,

Carrier IDs are used as an attribute to affect routing.  Carriers have 
multiple switching points that can be contacted through some type of 
signaling address.  Within a switching center, there are multiple trunk 
groups to other switching centers which may belong to the same carrier or 
different carriers.  Choosing a TG from that switching center determines 
what next switching center the call can be routed to, and by inference, 
what the next hop carrier will be.  Therefore, the carrier ID can determine 
what TG will be selected from that switching center.

The originating side wants to route to a given carrier and location and 
uses the inferred signaling address.  The destination side maps the carrier 
to an appropriate trunk group to get to that carrier and destination user 
address.

The 101 prefix dialing is just a method of indicating the carrier to use at 
by the switch terminating the local loop.  The fact that the next switching 
center can reach another carrier through another TG would be irrelevant, if 
the information was facility-based and not subverted by business 
arrangements.  But, given those business arrangements, what you are 
pointing out is that the CIC:TG relationship is not hierarchical and thus a 
TG could have multiple carriers associated with it.  That holds true if 
circuits are shared across carriers and the originating user is not 
affected by this business arrangement (i.e. charged for the next-hop 
facilities used to reach the desired carrier).

Question 1:  If 2 carriers were reach able over the same T-3, with one 
directly reachable and the other indirectly reachable, would the gateway 
almost always allocate the one physical facility as 2 logical trunk groups 
anyway?  (Thus restoring the TG infers CIC mapping.)

We already know that any switch in the PSTN can reach any other.  The real 
question is how to route such that the PSTN path is minimized at the 
expense of a more direct IP path (assumes that is the least cost 
path).  The use of TG data should be of local significance only at the 
egress of the IP network.

I agree with your call for some type of geographic attribute.  But, I don't 
understand your final statement.  I don't want to see carrier's charges on 
my bill, if as the caller I specify a particular long-distance or 
international carrier.  Also, will the CIC always be based on national body 
registration, or will IANA or someone ever assign international CIC codes 
for global carriers?

Mike

At 05:37 AM 12/31/2001 -0600, Peterson, Jon wrote:

>I wanted to speak a bit to the issue from the minutes below regarding the
>ubiquitous availability of carriers through trunks in the PSTN, and the
>relevance of the 'equal access' concept - especially since this a matter on
>which Dave and I have differed for some time.
>
>There are a number of ways (thanks to equal access provisions) that a user
>can directly or indirectly select a carrier, for example:
>
>- Having an entry in the LIDB for their address corresponding to the Carrier
>Identification Code of their chosen carrier, so that inter-exchange calls
>generated from their address always pick up this CIC (i.e. PIC LD).
>
>- Using a dial-around (101+XXX+address) to override the default CIC for
>their line.
>
>- Dialing a freephone number whose SMS/800 dip returns a CIC code -
>presumably once the call has been routed to the administrative domain of the
>carrier, a further internal dip will be performed to translate the freephone
>number into a geographic number.
>
>Dave is certainly correct that a CIC does not necessarily correspond to some
>physical network - that is, the concept of a 'carrier' chosen by a user is
>largely a matter of who issues your bill, not what physical infrastructure
>your call crosses. For example, there are resellers of long-distance service
>whose CICs are really just aliases for the CIC of a major carrier. Large
>carriers may own several CICs they use to target their services. It's
>certainly not some kind of one-to-one mapping from CICs to physical
>infrastructure.
>
>HOWEVER, this doesn't mean that a decision isn't made, in some places in the
>telephone network, about how a call is routed based on the CIC. In SS7, when
>a CIC has been selected for a call, it is carried within the TNS or
>(ANSIfied) CIC parameter of the Initial Address Message. The presence of
>this parameter modifies how a call is routed through the telephone network,
>especially at tandems.
>
>So, to bring this matter back to trunk groups, one view might be that a
>given trunk group may be considered to be a route to a CIC if, when an SS7
>IAM message carrying this CIC is sent over the trunk group, this call will
>(eventually) be routed to the administrative domain responsible for the CIC
>(and presumably get delivered appropriately). One might contend, as an
>opposing position, that only the carrier that owns the switch on the far
>side of the trunk should be considered to be reachable through a trunk - but
>I suspect that in an overflow situation most network would be content to
>send calls for some other carrier through such a trunk group, even if it
>introduced a middle-man network, complicating routing and potentially
>settlement.
>
>The correct position is probably somewhere in the middle. One or more CICs
>may be 'preferred' for a particular trunk by some switch in the network,
>largely because of who happens to own the equipment on the other side, but
>in addition all CICs are usually 'available' through such trunks. Something
>similar, I think, is true of E.164 numbers; certain ranges may be preferred
>(due to settlement concerns) for particular trunk groups, but all number
>ranges are usually available.
>
>Finally, it's important to note that CICs are national in scope, and that
>therefore trunk groups are most likely only routes to the set of CICs within
>a particular nationality. There have been suggestions in the past that
>identifiers for CICs in the gw reg mechanism should be concatenated with
>some sort of country code to provide a scope of a CIC - I would agree that
>this is probably necessary. Then we could refine our characterization of
>trunk group CIC routes to one in which all carriers for a given nationality
>could be 'available' through a trunk group.
>
>Jon Peterson
>NeuStar, Inc.
>
> > Further discussion:
> >
> > Jon said that he believes this should always be about TGs - believes
> > should treat PRI as a trunk. Cullen asked whether there would ever be
> > more than one carrier on a single trunk? Jon said that there are a
> > number of carriers for virtually every trunk.  Due to EA. Dave Oran
> > responded that this has nothing to do with it, as the EA concept user
> > experience doesn't necessarily relate.  Take it to the list.
> > >

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 3 Jan 2002 02:49:13 -0600

I don't think we're really disagreeing about much of what you say below. I
agree with your account of how things operate in the PSTN. It sounds like we
agree that the relationship of CICs to TGs is not in any simple way
hierarchical.

The primary purpose of my note on the CIC was to suggest a potential litmus
test for whether or not a CIC was routable through a TG. I think that's an
important definition for us all to agree on if we're going to consider
propagating attributes like CICs in the gw reg protocol.

In answer to the question you pose, I think my contention here is that one
logical trunk group could have more than one CIC associated with it. Imagine
a trivial VoIP network containing one proxy server and one PSTN gateway in
which the gateway had a single trunk group aimed at an access tandem.
Clearly, that trunk group would be the route for all CICs irrespective of
whether it was directly or indirectly connected to any given carrier.
Introduce a second trunk group going to a different access tandem, and
perhaps this trunk group would be a better route for some set of CICs. But
in neither case would you want to construct, say, one logical trunk group
per CIC and overlay them all on the physical trunk(s) - that would be quite
an administrative headache.

I'm not sure I necessarily agree that the question with CICs is "how to
route such that the PSTN path is minimized at the expense of a more direct
IP path", or even that this is necessarily a least-cost problem. There have
been significant head-end hop-off vs. tail-end hop-off arguments with regard
to CIC routing levied here in the past. Fortunately, I think this is
ultimately a routing policy question, and really any of these philosophies
could be enabled by the CIC propagation systems we're discussing above. 

And, my final statement in my previous mail was intended only to illustrate
that CICs are national in scope - that's all.

Jon Peterson
NeuStar, Inc.

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Wednesday, January 02, 2002 4:41 PM
> To: Peterson, Jon
> Cc: iptel
> Subject: RE: [IPTEL] draft meeting minutes
> 
> 
> Jon,
>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 03 Jan 2002 10:47:13 -0500

Yes, I think our perspectives are consistent.  What I have a problem with 
is getting wrapped around the axle with propagating routing information 
across the network, that in the end may not provide a useful discriminator 
for choosing one route over another.  What makes one gateway hop-off point 
better than another?

Are we minimizing PSTN (or other) network administrations that we must cross?
Are we minimizing conversion points (RTP to TDM) that may introduce noise?
Can a network capacity re-seller reduce the number of billing relationships?

My starting axiom was that the call was routed into the IP world or started 
there for a reason, and that IP was the preferred path to effectively make 
all calls local.  Your point that the existing CIC codes are inherently 
geographical on a large scale also points to the possible need to define 
geographic attributes on a smaller scale as well.

Mike

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 4 Jan 2002 17:19:01 -0600

I certainly think you have a valid concern; there definitely is a
relationship between the attributes propagated by the gateway registration
protocol and the routing decisions (for call setup signaling) made by the
proxies that receive these registrations. TRIP strongly couples the two - in
fact, TRIP provides for three major functions:

1) The protocol itself for propagating routes from one point to the next 
2) Way of making forwarding decisions for calls based on discriminators
propagated in the protocol (TRIBs)
3) Way of deciding what routes you will share with peers

By ruling intradomain route propagation outside of the scope of the gw reg
deliverable, we've essentially made the third item above out of scope. None
of our existing requirements, I think, really address the second problem -
nor have we necessarily agreed that this problem is even in the scope of
gateway registration. I'd really like to hear people's opinions about that.

I definitely agree that discriminators should provide enough data to allow
meaningful routing decisions to be made by proxy servers; however, I don't
think we should wed discriminators to any particular routing philosophy. I
think ideally, the set of discriminators should be flexible enough to enable
any of the hop-off philosophies you describe below, depending on the policy
of the service provider accepting gateway registrations (a little MAAP, I
know). I would be really cautious about any gw reg protocol that seemed to
limit the sort of forwarding decisions that might be made within the proxy
server. 

Note that, as I understand it, TRIP builds in some limitations here (like
hierarchical discriminators).

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, January 03, 2002 7:47 AM
> To: Peterson, Jon
> Cc: iptel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 04 Jan 2002 18:55:33 -0500

Jon,

I am also assuming that, while some information may be provisioned directly 
into the LS or available through other protocol mechanisms, much of the 
data shared with peers internal or external to the administrative domain 
will be derived from the data learned through the GW-Reg.  So, there may be 
stuff put in GW-reg because the follow-on protocols expect to be able to 
pass that data.

Mike

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 8 Jan 2002 06:30:37 -0600

That may be true, and it's probably something we shouldn't lose sight of -
however, we have made a clear choice of scope to focus on the gateway
registration problem rather than the intradomain route propagation problem,
for the moment. I think (Jonathan can correct me if I'm out of line) the
prevailing philosophy of the WG is that we consider gw reg as its own
problem, and if it turns out that the result has applicability to, say,
intradomain route propagation, that's fine, but intradomain route
propagation can't be a source of requirements for the gw reg problem.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, January 04, 2002 3:56 PM
> To: Peterson, Jon
> Cc: iptel

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Tue, 8 Jan 2002 10:25:32 -0500

Please see comments inline [RRR].

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 7:31 AM
To: 'Michael Hammer'
Cc: iptel
Subject: RE: [IPTEL] draft meeting minutes

for the moment. 

[RRR] I would rather agree with this because I have made a contribution for the complete protocol set ((http://www.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt)) for intra-Domain because the intra-Domain requires the following: 1. GW <-> LS communications and 2. LS <-> LS communications.

[RRR] For the sake of making progress, I would rather propose, as Jon pointed out, let us start item 1 first (GW <-> LS) where registration and discovery are the most important features. The reason is that, in an intra-Domain, many GWs and one location server may a good start for a small network. In some cases, a single location server may be good enough among multiple SIP proxies (assuming proprietary protocol is used between the SIP proxies and the LS when they are not colocated).

[RRR] However, we also need to address the item 2 sooner or later (and the above draft is a good start) because a large network will have multiple location servers.

I think (Jonathan can correct me if I'm out of line) the

[RRR] A good test will be to look into the draft as referred above. But you are right that we need to address the intra-Domain communications at some point of time. In the meantime, I have sent a draft proposing the "Framework on Intra-Domain Communications Protocol." While we are developing the GW registration protocol, we can also keep our eyes open how the complete picture will look like when think about the "Intra-Domain" protocol.

Jon Peterson
NeuStar, Inc.