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

From: Li Li <[email-masked]>
Date: Mon, 26 Aug 2002 09:21:09 -0400

It may be useful in cases where the origating trunk group 
and terminating trunk group need to be distinguished. 
So "otgrp=trunk_group_label1", "dtgrp=trunk_group_label2"
type of format may help.

Thanks,

Li Li

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Wednesday, August 21, 2002 2:39 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Jon Peterson;
> [email-masked]
> Subject: [Sipping] 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

---

From: Adam Roach <[email-masked]>
Date: Mon, 26 Aug 2002 12:23:08 -0500

[Trimming the "to" list; I think the mailman software might be
 shoving these off into la-la land because it was too long.
 Apologies if this message surfaces more than once]

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

> Sent: Wednesday, August 21, 2002 13:39
> [email-masked]; [email-masked]; Jon Peterson;
> [email-masked]
> Subject: How to indicate trunk groups in URI?
> 
> 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 26 Aug 2002 17:08:15 -0500

One hates to be a fly in the ointment, but... three things about putting a
TG parameter into a hostname. First, on a small point, I imagine that many
of the calls that are sent to gateways today have no hostname portion of the
Request-URI - one reason to send a call to a gateway is that you cannot
follow RFC3263 procedures for the Request-URI because it is a tel URL.
Second, on a more serious point, in my experience carriers distribute trunk
groups across two or more trunking gateways for availability purposes; in
other words, I believe there can be multiple gateways/hostnames associated
with a trunk group identifier - it should be possible to select a trunk
group as a route without specifying which gateway associated with the trunk
group the call will land on (I'll motivate this if it seems
counterintuitive). Third, most seriously, Adam's proposal (following the
other examples in this thread) uses a simple trunk group syntax ("group-a")
that is RFC1034-safe; but I believe that there are good reasons to use a
more complicated syntax, since there are potentially many existing trunk
group naming conventions that we should accomodate, and therefore we
probably need a little more structure in the name. Some conventions for
trunk groups in the PSTN today (and in some SIP-based architectures I've
seen bandied around) even have 'cross-domain' significance, and thus I
believe that there is a demonstrable need for standardization.

I wrote an I-D that broadly models the interaction of trunk groups with
gateways (in the context of gateway registration rather than SIP routing,
but it has a framework that might be a good starting place for discussion).
It seems to have expired last week, but is still available at:

http://www.potaroo.net/ietf/ids/draft-peterson-iptel-gwreg-arch-00.txt

This draft speaks to how we might consider the trunk group as a resource to
be available behind a gateway, why one might want to make routing decisions
based on a trunk group rather than any other sort of address, and so on.
I'll resubmit it.

I agree with Adam that adding a SIP URI parameter for a trunk group probably
isn't the right idea. However, I think that adding a tel URL parameter for
trunk groups wouldn't suffer from many of the same problems. Using this tel
URL parameter in any of the typical URI positions in a SIP request where a
tel URL appears (From, Request-URI, Contact, etc) seems reasonable to me.
Remember of course that a tel URL can be a component of a SIP URI as well. I
have come to look at the tel URL as a good repository for any
telephony-specific addressing information that would never have any
corollary in native SIP - trunk groups definitely qualify.

I circulated a proposal along these lines informally (off the mailing list)
last year, and I have quite a few notes towards a proposal. I'd be happy to
work with any parties interested in pushing this concept forward. Or if
people are interested I could just dump my notes to this list... the hard
part is not choosing a place for the information to reside in the message, I
think - it's choosing the syntax for the trunk group identifier itself.

Jon Peterson
NeuStar, Inc.

> From: Adam Roach [mailto:[email-masked]]
> Sent: Monday, August 26, 2002 12:21 PM
> To: 'Vijay K. Gurbani'; Adam Roach
> Cc: [email-masked]
> Subject: RE: [Sipping] RE: How to indicate trunk groups in URI?
> 
> 
> > From: Vijay K. Gurbani [mailto:[email-masked]]
> >
> > Absence any guidelines, we will stumble on ahed making ad-hoc 
> > decisions on how to do this.  
> 
> Right. I was getting there. First, I wanted to make sure that the
> virtual-host solution met everyone's requirements. If we can
> get some agreement on that, my next step will be proposing that
> we put together a BCP describing this mechanism and publish it as
> an informational SIPPING draft.
> 
> /a

---

From: [email-masked]
Date: Mon, 26 Aug 2002 23:18:41 EDT

In a message dated 8/26/02 12:15:20 PM Eastern Daylight Time, 
[email-masked] writes:

This comes from the Gateway Registration work in the IPTEL group. It
represents resources in or beyond the gateway. Jon Peterson's just expired
draft (draft-peterson-iptel-gwreg-arch-00.txt) describes an architecture for
using trunk groups in gateway registration.

[MAP] I think the referenced Peterson draft contains the correct definition 
of "trunk" and "trunk group". There was another definition floating around 
that was causing trouble by relating it to what numbers were reachable 
through it.

The thing in the Peterson draft that might cause some difficulty is the 
notion of a single "Trunk Group" spanning multiple gateways. It seems to 
reflect the incorrect definition by referring to a Trunk Group spanning GW1 
and GW2, maybe only because a common set of phone numbers (+1202 and 
+1704...) are reachable through both parts. The question is whether or not 
there is any requirement to support this case (spanning GWs). It would seem 
that supporting this spanning would significantly complicate any use of the 
registration function.

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: "Peterson, Jon" <[email-masked]>
Date: Tue, 27 Aug 2002 02:17:28 -0400

FWIW, I don't believe it is problematic to state that a single trunk group
can span multiple trunking gateways - in fact, I am aware of at least one
operator that has adopted this architecture. In the example in question, the
TG is not said to span GW1 and GW2 merely because the two gateways happen to
have favorable access to the same exchanges - it is intended to signify that
a range of TCICs under the same policy (a TG) have been connected to two
separate physical devices. I believe there is a requirement to support this
case - striping a TG across multiple gateways provides redundancy for the
TG, in the opinion of some providers. For example, it allows providers to
quiesce those flaky gateways for frequent maintenance without bringing the
entire TG down - only half the TG need be brought down at a time.
 
Also note that the registration function, thankfully, is not the concern of
this mailing list. :)
 
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?

Mike Pierce 
Artel

---

From: [email-masked]
Date: Tue, 27 Aug 2002 08:49:49 EDT

In a message dated 8/27/02 2:17:42 AM Eastern Daylight Time, 
[email-masked] writes:

> operator that has adopted this architecture. In the example in question, 
> the TG is not said to span GW1 and GW2 merely because the two gateways 
> happen to have favorable access to the same exchanges - it is intended to 
> signify that a range of TCICs under the same policy (a TG) have been 
> connected to two separate physical devices. I believe there is a 
> requirement to support this case - striping a TG across multiple gateways 
> provides redundancy for the TG, in the opinion of some providers. For 
> example, it allows providers to quiesce those flaky gateways for frequent 
> maintenance without bringing the entire TG down - only half the TG need be 
> brought down at a time.
> 

[MAP] Yes, I agree that it appears favorable, but the situation you mention 
(redundancy) can be provided by simply defining it as multiple trunk groups, 
one to each GW. The problem of spanning multiple GWs is for the other end 
which then has a trunk group that goes to two different devices. The 
situation you mentioned for having to take one GW down for maintenance is 
exactly the problem. Signalling provides ways to efficiently block or reset a 
trunk group, but if only half needs to be blocked (because they know the GW 
is going to come down), it has to be done trunk by trunk, rather than just 
doing the group.

As stated in the definition you quoted, a trunk group is "a communication 
path connecting two switching systems". One could say that the two GWs (and 
their controller) constituted one system for the sake of this definition, and 
that would be correct, but I like to think of them as distinct devices for 
identification of trunk groups.

Mike Pierce
Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 27 Aug 2002 11:03:04 -0500

Yes, agreed. A trunk group can span multiple media gateways that are
controlled by the same media gateway controller; that are part of the same
switch. Clearly a TG shouldn't span devices that are addressed by different
SS7 point codes.

Jon Peterson
NeuStar, Inc.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, August 27, 2002 7:57 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [Sipping] How to indicate trunk groups in URI?
> 
> 
> Tom hits the nail on the head.  We only need to ensure we do 
> not preclude
> the possibility of handling a single MGC with a trunk group spanning
> multiple MGs.  To a carrier on the other end of the trunk 
> group, this looks
> just like a single PSTN switch.  They do not know or care 
> that the trunks
> are stripped across multiple MGs.
> 
> John Hearty
> Level3
> 
> > From: Tom-PT Taylor [mailto:[email-masked]]
> > Sent: Tuesday, August 27, 2002 7:12 AM
> > To: [email-masked]'; 'Peterson, Jon'; [email-masked]
> > Subject: RE: [Sipping] How to indicate trunk groups in URI?
> > 
> > 
> > On the point of trunk groups split across gateways: it 
> > depends on whether
> > the gateway is analogous to a PSTN switch peripheral or to a 
> > PSTN switch.
> > "Gateway" in the Megaco sense corresponds to the former, 
> > hence it would be
> > quite reasonable according to typical PSTN practice to split 
> > trunk groups
> > across Megaco gateways.  In the present discussion, however, 
> > I think we are
> > using the term "gateway" for something which is analogous to 
> > the entire PSTN
> > switch.  Thus I agree with Mike's assertion that the term 
> > "trunk group" is
> > inappropriate for something supported by multiple gateways.  
> > The closest
> > PSTN term I can come up with is "route".
> > 
> > Sent: Monday, August 26, 2002 11:19 PM

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Aug 2002 15:42:49 -0400

The telco can only administer all those trunks as a single trunk group if
the group is one-way incoming to the PSTN switch, and that is stretching
things a bit because the traffic engineering model is complicated (traffic
capacity potentially reduced) by the need to fork at the proxy when an
all-trunks-busy condition is encountered at a given gateway.  In the
outgoing direction each gateway appears by hypothesis as a separate
signalling entity, and the related signalling information tends to be
configured in the switch at the trunk group level.  Thus you would have to
have a separate outgoing trunk group per gateway.  

Another point is that trunk group names are local to the switch.  That is,
the same trunk group has a different name at each end, in general.
Typically the name at one end includes the name of the switch at the other
end, plus additional information relating to the trunk group type,
direction, and possibly other information.

All this is academic.  From the SIP network point of view, the real
requirement is for a URI convention to designate a single route which can be
reached through a number of gateways which advertise accessibility to that
route.  If we are talking about a URI parameter, then the content of that
parameter is the route name which is also used as an identifier for
advertisement.

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 11:17 AM
To: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; 'Peterson, Jon';
[email-masked]

In this context, we are talking about a proxy which has determined that a
call needs to go to a given resource which exists behind multiple gateways.
That resource is a set of trunks. In this case, that set of trunks terminate
on a single PSTN switch, but they are connected to multiple gateways. On the
PSTN side it is a single trunk group, and that is the resource that needs to
be expressed. For the SIP routing, based on things like destination number
and preferred carrier, the desired target of the call is that single trunk
group. The information used to make the routing decision (carrier,
destination-prefix, trunk-group, circuit availability, etc) can be learned
from TRIP-GW, but that's a discussion for the IPTEL list. Once that target
trunk group has been determined, the SIP proxy must then select one of the
gateways connected to that trunk group to send the request to.

I think a URI parameter is the best way. The trunk group label itself can be
arbitrary since it is owned by the PSTN switch the gateways connect to. Only
the parameter name needs to be standardized. If a gateway registration
protocol (like TRIP-GW) is being used, the trunk group information only
needs to be provisioned in the gateways. All the SIP proxy needs to do is
take that label it learned and add it to the URI as a trunk group parameter.

cheers,
(-:bob

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

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>
To: <[email-masked]>; "'Peterson, Jon'" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, August 27, 2002 9:11 AM
Subject: RE: [Sipping] How to indicate trunk groups in URI?

> On the point of trunk groups split across gateways: it depends on whether
> the gateway is analogous to a PSTN switch peripheral or to a PSTN switch.
> "Gateway" in the Megaco sense corresponds to the former, hence it would be
> quite reasonable according to typical PSTN practice to split trunk groups
> across Megaco gateways.  In the present discussion, however, I think we
are
> using the term "gateway" for something which is analogous to the entire
PSTN
> switch.  Thus I agree with Mike's assertion that the term "trunk group" is
> inappropriate for something supported by multiple gateways.  The closest

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 28 Aug 2002 12:28:32 +0200

Hi,
this discussion is very interesting from the (PSTN) operator point of view.
Because for interconnection with other carriers (PSTN) indications are needed for billing purposes (e.g. online/offline billing). This indications for the registration of the traffic can be the Trunk Group and the destination can see how to handle the traffic. You can separate traffic streams.

Tom said that the TG name is local to the switch, that is correct. But in an interconnection case between two carrier each carrier (switch) knows that TG, that is based on the OPC,DPC and CIC.

A MGC, controlling several MG has to know which MG is terminating groups of CIC's (Trunk Groups) with a OPC/DPC combination. Of course in the case the MGC is presenting several SPC's it has to know which MG (or part of the MG) belongs to that SPC.

So if you want to send the TG-Name with the URI it is  an indication of the traffic.

I would like to support David of specifying a URI Parameter or (what I think it is better) a own header for the CIC (carrier identification code)  and some other indications that are needed for traffic indication purposes. That helps provider  to indicate traffic (ISBN-SIP or SIP-SIP traffic)  for interconnection scenarios.

Best Regards

Roland Jesske

Deutsche Telekom AG
T Com Zentrale
Section T38; Signalling, Gateways and Switching Systems 
Roland Jesske, T38a12
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
mailto: [email-masked] <mailto:[email-masked]> 

> -----Ursprungliche Nachricht-----
> Von: Tom-PT Taylor [mailto:[email-masked]]
> Gesendet: Dienstag, 27. August 2002 21:43
> An: 'Bob Penfield'; [email-masked]
> Betreff: RE: [Sipping] How to indicate trunk groups in URI?
> 
> 
> 
> > draft (draft-peterson-iptel-gwreg-arch-00.txt) describes an 
> architecture
> for
> >
> > reflect the incorrect definition by referring to a Trunk 
> Group spanning
> GW1
> > there is any requirement to support this case (spanning 
> GWs). It would
> seem
> > that supporting this spanning would significantly 
> complicate any use of
> the
> > registration function.
> >
> > standardized identification for each entity (gateway in 
> this case). It
> seems

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 28 Aug 2002 13:47:42 +0200

Hi,

Best Regards

Roland Jesske

Deutsche Telekom AG
T Com Zentrale

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 28 Aug 2002 22:01:48 -0500

Just FYI, a proposed mapping for the carrier identification code in ISUP to
a tel URL parameter is already given in:

http://www.ietf.org/internet-drafts/draft-yu-tel-url-05.txt

I believe an -06 is about to be released, so this hyperlink may not work for
very long.

Jon Peterson
NeuStar, Inc.

> From: Jesske, R [mailto:[email-masked]]
> Sent: Wednesday, August 28, 2002 4:48 AM
> To: [email-masked]
> Subject: AW: [Sipping] How to indicate trunk groups in URI?
> 
> 
> Hi,
> Because for interconnection with other carriers (PSTN) 
> indications are needed for billing purposes (e.g. 
> online/offline billing). This indications for the 
> registration of the traffic can be the Trunk Group and the 
> destination can see how to handle the traffic. You can 
> separate traffic streams.
> 
> Tom said that the TG name is local to the switch, that is 
> correct. But in an interconnection case between two carrier 
> each carrier (switch) knows that TG, that is based on the 
> OPC,DPC and CIC.
> 
> A MGC, controlling several MG has to know which MG is 
> terminating groups of CIC's (Trunk Groups) with a OPC/DPC 
> combination. Of course in the case the MGC is presenting 
> several SPC's it has to know which MG (or part of the MG) 
> belongs to that SPC.
> 
> I would like to support David of specifying a URI Parameter 
> or (what I think it is better) a own header for the CIC 
> (carrier identification code)  and some other indications 
> that are needed for traffic indication purposes. That helps 
> provider  to indicate traffic (ISBN-SIP or SIP-SIP traffic)  
> for interconnection scenarios.
> 
> Best Regards
> 
> Roland Jesske
> 
> 
> Deutsche Telekom AG
> T Com Zentrale
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Chaney, Charles" <[email-masked]>
Date: Thu, 29 Aug 2002 11:25:54 -0400

I think there is some confusion in the use of the 'CIC' term. In this
context, CIC is referring to Circuit Identification Code included in ISDN
User Part (ISUP) messages, not the 'Carrier Identification Code' used for
identifying the carrier to be used for handling the call. The Circuit
Identification Code is typically associated with a trunk group defining
properties like bilateral agreements between switches as mentioned in the
text below. The reference you gave refers to the Carrier Identification Code
used for features like freephone (or 8xx number) service.

Regards,
Chuck Chaney
Siemens, ICN

> From: Peterson, Jon [mailto:[email-masked]]
> Sent: Wednesday, August 28, 2002 11:02 PM
> To: 'Jesske, R'; [email-masked]

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 29 Aug 2002 12:01:08 -0400

Actually, if you read the last paragraph of Roland's note, and the note by
Dave Oran with which Roland is agreeing, you will see they are in fact
talking about the Carrier Identifiation Code. Roland just happens to mention
both meanings of CIC in his mail.

Jon Peterson
NeuStar, Inc.

> From: Chaney, Charles [mailto:[email-masked]]
> Sent: Thursday, August 29, 2002 8:26 AM
> To: 'Peterson, Jon'; 'Jesske, R'; [email-masked]
> > > > > [MAP] I think the referenced Peterson draft contains 
> the correct
> > > > definition