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

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

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

> -----Original Message-----
> 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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 26 Aug 2002 13:50:44 -0500

> trunk group names are, since it's strictly an administrative issue).

Right; I am not proposing we standardize all the valid values of
trunk groups, rather just the means to deliver them from a proxy to
a gateway and vice versa; i.e. standardize the name of the parameter,
not the set of all the possible values of the parameter.

Your idea for DNS wildcarding is very useful; and I guess it can also be
used in the opposite direction -- passing *ingress* trunk group to
the proxy from a gateway for routing decisions.

The bottom line is that there isn't any clean way to pass ingress
trunk groups from a gateway to a proxy or pass egress trunk groups
from a proxy to a gateway.  DNS is one option, standardizing on a
parameter name (like dtg):

    INVITE sip:[email-masked];dtg=20

is another.

Absence any guidelines, we will stumble on ahed making ad-hoc decisions
on how to do this.  For example, I have even observed proxies passing
trunk group information by pre-pending n bytes to user portion of the
R-URI.  The gateway then consumes exactly these n bytes from the
user portion.  That is great if one wants to couple the proxy and
gateways tightly, but not so good if you want best-of-breed solutions
where a proxy from one vendor can control gateways from multiple vendors
without any such coupling.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 30 Aug 2002 15:56:12 -0700

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?
>
>