Subject: RE: [Sipping] How to indicate trunk groups in URI?

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 2 Sep 2002 15:56:18 -0500

One of the pieces of the puzzle on trunk group identifiers that is currently
largely unexplored is information on standardized schemes for trunks and
trunk groups. Any draft that proposes a way to carry trunk groups in SIP
should probably have some concept there are multiple possible trunk group
formats, declare an IANA namespace for managing these formats (including
standard and private trunk group formats), and provide at least one or two
common and useful formats in the draft itself.
 
If anyone out there is aware of standard trunk group formats in use in the
PSTN today that are described in specifications that we could reference in a
draft, I for one would be interested to hear about them. Anything from trunk
group conventions used in RBOC order/augmentation forms to NFAS groups of
PRIs to old MF identifiers would be appreciated.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 26, 2002 8:19 PM
To: [email-masked]; [email-masked]
Subject: Re: [Sipping] How to indicate trunk groups in URI?

[snip] 
There are already standardized schemes to refer to trunks and trunk groups
between PSTN switches (at least in the US). They generally begin with a
standardized identification for each entity (gateway in this case). It seems
that the task here is coding those identifiers into a URL-type format, not
defining a new scheme 

Mike Pierce 
Artel

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 2 Sep 2002 14:53:14 -0700

Cullen, 

That could be solved by simply scoping the trunk group name to the domain
rather than a proxy (e.g. DNS lookup for tg55.domain.com).

You could use a recursive process as well I guess. 

tg55.domain.com -> tg55.proxyB.domain.com -> tg55.gatewayC.domain.com

Robert.

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: 30 August 2002 23:56
> To: Adam Roach; 'Cullen Jennings'; [email-masked]
> Subject: RE: [Sipping] RE: How to indicate trunk groups in URI?
> 
> 
> 
> I was quite enamored with this proposal at first but I think 
> I have a major
> problem with it that I don't see how to solve.
> 
> Imagine ProxyA knows that it wants to send the call to a 
> trunk group called
> tg55 and it has learned  (perhaps via TRIP) that ProxyB can 
> handle calls to
> tg55. Now ProxyB might have several gateways gw2, gw3, and 
> gw5 that handle
> calls to this trunk group but ProxyA does not know anything 
> about this.
> 
> ProxyA wants to send an INVITE with something like 
> tg55.*.proxyB.com to
> proxyB. This GW wildcard seems unreasonable.
> 
> Ideas to solve this?
> 
> Cullen
> 
> 
> 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Adam Roach
> > Sent: Monday, August 26, 2002 9:40 AM
> > To: 'Cullen Jennings'; [email-masked]; [email-masked];
> > [email-masked]; Adam Roach; Jon Peterson;
> > [email-masked]
> > Subject: [Sipping] RE: How to indicate trunk groups in URI?
> >
> >
> > First of all, I think we need to have a common understanding of
> > the requirements for communicating this information. Is it cross-
> > domain? Would that even make any sense?
> >
> > Judging from the work I've done with carriers on this issue in the
> > past, the selection of the trunk group at the terminating gateway
> > is something done by a proxy or redirect server that is owned by
> > the same entity as owns the PSTN gateway. This greatly simplifies
> > the issue, since it no longer needs to be strictly standardized
> > (in other words, we don't need to agree on what valid values of
> > trunk group names are, since it's strictly an administrative issue).
> >
> > I have objections to the proposals that Vijay floated.
> >
> > >    0) Do nothing
> >
> > Presumably, this wasn't thrown out as a serious option.
> >
> > >    1) Standardize the name of the R-URI parameter for a 
> trunk group
> >
> > I hesitate to extend the protocol unnecessarily. Also, this 
> suggestion
> > is directly in violation of RFC 3087.
> >
> > >    2) Come up with a new header
> >
> > As before, I hesitate to extend the protocol unnecessarily. This
> > approach feels particularly wrong because it is putting information
> > that is intrnsically associated with the Request-URI in a header
> > field -- which is just asking for headaches.
> >
> > >    3) Append it to the To tag
> >
> > Vijay shot this one down himself.
> >
> > >    4) <Any others that I may have missed>
> >
> > I like this one the best. :)
> >
> > When you have a single PSTN gateway serving multiple trunk groups,
> > it can be conceptually modeled as multiple gateways, each serving
> > one trunk group. Everyone agrees that this mode of operation is
> > fairly simple to provision in the nodes that select the appropriate
> > trunk group.
> >
> > When you think about it this way, it feels *just* *like* web
> > virtual hosting, doesn't it?
> >
> > Admittely, the number of trunks that you want to communicate might
> > be large, and you don't necessarily want to have a DNS entry
> > for each of them -- but DNS wildcards solve this problem quite
> > handily.
> >
> > What does this mean in practice? Well, for a particular gateway
> > (let's call it gw-4-17), you could add an entry to DNS like:
> >
> > *.gw-4-17.example.com. IN A 192.168.4.17
> >
> > Now, you can provision the gateway at 192.168.4.17 with three
> > trunk groups (call them group-a, group-b, and group-c), and
> > provision your proxy/redirect server/whatever to treat these
> > as three different URIs. In other words:
> >
> > INVITE sip:[email-masked] SIP/2.0
> >
> > would be routed to the gateway, which would then be able to
> > extract "group-a" from the request URI and consequently select
> > trunk group A. Similarly:
> >
> > INVITE sip:[email-masked] SIP/2.0
> >
> > would be routed to the same gateway, which would use
> > trunk group b to complete the calls.
> >
> > Why do I like this approach so much? There are a variety of
> > reasons:
> >
> > 1) It requires no additional standardization, just additional
> >    requirements on PSTN gateways (which any standardization
> >    for trunk group selection would require as well).
> >
> > 2) It allows for simple network maintanance. If, for example,
> >    you had a gateway serving 8 trunk groups, and it became
> >    too busy, you could trivially drop in a second gateway,
> >    move half the trunks to it, tweak DNS, and be up and
> >    running -- all without having to touch any of the other
> >    nodes in the network.
> >
> > 3) It is consistent with the spirit of RFC 3087.
> >
> > Back in my previous life, we sucessfully deployed this
> > approach in service provider's labs, with good results.
> > Does anyone have requirements on selecting trunk groups that
> > this approach does not address?
> >
> > /a
> >
> > > From: Cullen Jennings [mailto:[email-masked]]
> > > Sent: Wednesday, August 21, 2002 13:39
> > > To: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]; Jon 
> Peterson;
> > > [email-masked]
> > > Subject: How to indicate trunk groups in URI?
> > >
> > >
> > >
> > > In a tel URL (or the SIP conversion of it) a carrier
> > > identification code can
> > > be done with a tag like "cic=+1-0288". Does anyone see 
> any issues with
> > > indicating trunk groups with a tag something like
> > > "tgrp=trunk_group_label"?
> > > Better ideas on how to do this?
> > >
> > > Thanks, Cullen
> > >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> >
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Adam Roach <[email-masked]>
Date: Tue, 3 Sep 2002 14:46:54 -0500

Jon has pretty much shut down this line of discussion by an
asserted requirement that trunk group identification cannot
be heirarchical (which DNS inherently is). However, since
your question addresses this exact point, it might be worth
pursuing.

> calls to this trunk group but ProxyA does not know anything 

In general, proxy A doesn't know -- and doesn't need to know --
anything about the topology behind proxy B. It sends the message
to proxy B with sufficient information in the message to allow
proxy B to process it correctly.

> proxyB. This GW wildcard seems unreasonable.

I'm rather confused by why you think the wildcard would be
necessary at all. As long as you are talking to nodes that have
some concept of this virtual hosting solution, the same scheme
applies. You would send the message to sip:[email-masked],
right? I must be missing something. Could you explain why
you think the additional ".*." would make sense?

/a

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 3 Sep 2002 18:28:17 -0400

Unless trunk-group names were a global namespace, propagating the trunk
group information beyond the gateway's proxy would be problematic.

Given the proposed architecture for TRIP-GW where the gateways would only
advertise the TG stuff to their proxy (ProxyB in your example) and the
TRIP-GW & TG stuff would not be advertised into the I-TRIP/E-TRIP network,
how would ProxyA learn about tg55? I would think that ProxyA would send the
request to ProxyB which would route it to the appropriate gateway.

CICs (Carrier Indicator Codes) can have a global names space and could be
propagated into the network. The CIC could be used to get the request to the
right gateway proxy and that gateway proxy could select the trunk group.

Even if the trunk group information was propagated to ProxyA, wouldn't that
information have a SIP server associated with tg55 that ProxyA was suppose
to send the request to?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Cullen Jennings" <[email-masked]>
To: "Adam Roach" <[email-masked]>; "'Cullen Jennings'"
<[email-masked]>; <[email-masked]>
Sent: Friday, August 30, 2002 6:56 PM
Subject: RE: [Sipping] RE: How to indicate trunk groups in URI?

>
> I was quite enamored with this proposal at first but I think I have a
major
> Imagine ProxyA knows that it wants to send the call to a trunk group
called
> tg55 and it has learned  (perhaps via TRIP) that ProxyB can handle calls
to
> tg55. Now ProxyB might have several gateways gw2, gw3, and gw5 that handle
> calls to this trunk group but ProxyA does not know anything about this.
>
> ProxyA wants to send an INVITE with something like tg55.*.proxyB.com to
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Adam Roach
> > >    1) Standardize the name of the R-URI parameter for a trunk group
> >
> > I hesitate to extend the protocol unnecessarily. Also, this suggestion
> > > [email-masked]; [email-masked]; Jon Peterson;
> > > [email-masked]
> > > be done with a tag like "cic=+1-0288". Does anyone see any issues with

---

From: [email-masked]
Date: Thu, 5 Sep 2002 12:46:33 EDT

In a message dated 9/3/02 4:23:27 PM Eastern Daylight Time, [email-masked] 
writes:

> Mike,
> 
> Could you clarify what you mean by gateway?  Does gateway correspond to the 
> equivalent of a switching system, i.e. an MGC with multiple controlled 
> media gateways, or do you refer to the media gateway itself?  It is not 
> clear to me whether you have a composed or de-composed model in mind.
> 
> Mike H.
> 

Good question. I presume that what Cullen was originally referring to was not 
a MG (part of a decomposed gateway). I don't like to discuss "composed" or 
"de-composed" gateways, since I believe that is an internal implementation 
option that is confusing the discussion. In my comments, a "gateway" is a box 
that contains media handling and control. You can implement that 
"de-composed" if you want, but it is not important here.

Yes, in this sense, a "gateway" is the equivalent to a switching system in 
the telephony archtecture. It's why I don't think a trunk group can be split 
across multiple gateways. (If you think of multiple MGs controlled by a 
single MGC, then it is okay for a trunk group to be split across muliple MGs, 
however, it still causes problems if one wants to use things like Trunk Group 
blocking when a MG goes out of service.)

Boy, does this discussion scream for a diagram!

Mike Pierce
Artel