Subject: [Sipping] RE: SUMMARY: Trunk groups in R-URI

From: Adam Roach <[email-masked]>
Date: Wed, 4 Sep 2002 17:35:56 -0500

Thanks for the summary! Some quick comments inline.

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
>
> As a summary of the discussion regarding indicating trunk groups,
> majority of the people who weighed in on this topic appear to 
> favor the
> approach of standardizing a URI parameter name (i.e. in a R-URI of the
> form: sip:[email-masked];dtg=23, 

In conversations I had with Jon, he advocated the position
(and I strongly agree) that we should not allow PSTN-specific
stuff to creep into the SIP URI scheme. These sort of
indications would feel right at home on the tel: URL scheme
(which is open for surgery right now, anyway). In any case,
there seem to be implied requirements that we can indicate
trunk groups on tel URLs (to quote Jon: "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"). Any such
parameters will naturally end up in the user portion when they
get translated to a SIP URI. Since it makes no sense to define
this mechanism twice when once is sufficient, it is only logical
that the solution would be a parameter on a tel uri; e.g.,
<tel:+12145551212;dtg=23>.

> the only thing to be
> standardized will be the parameter name 'dtg', NOT the trunk 
> group label
> '23').

As you mention elsewhere, Jon made some noise about trying to collect
the standardized systems for identifying trunks, so this statement
isn't necessarily uncontested. I don't know enough about the
specifics of trunk naming to have much of an opinion on the topic.
Perhaps we should seek guidance outside the working group on this issue?
Maybe it's an orthagonal problem?

>        1/ Adam Roach proposed using the httpd virtual host idea here
>           through wildcarding DNS entries (essentially the trunk group
>           labels would be wildcarded in DNS zone files).  This idea
>           was deemed good for an enterprise, but maybe not as 
> applicable
>           in a wider context since DNS is inherently heirarchical and
>           trunk group labels do not lend themselves well to such
>           heirarchical representations.

More expressively: there was an objection on the grounds that
trunk groups can be split across multiple gateways, and that the
DNS approach as written didn't address this situation very
gracefully. After further reflection, I can't see how a parameter
is superior to a portion of the hostname for conveying trunk group
information, since the next-to-last-SIP-hop sender will still be
required to select which gateway the request ultimately goes to.

The most convincing objection to my proposal is the one I raised
earlier in this note: if we're already doing this to the tel URL,
then we get it for free in the SIP URI, and there's no reason to
do things twice.

>        2/ Jon Peterson raised the notion of putting the trunk group in
>           a tel URI.  Problem is that when the tel URI gets 
> transformed
>           to a SIP URI, the parameter will end up in the userinfo part
>           of the SIP URI, and at least semantically, not be treated as
>           a parameter.  But this approach is still better than having
>           no guidance at all since it will, at the very least,
>           standardize the name that will appear in a tel (and
>           subsequently, a transformed SIP) URI.

I'm not certain I see this as a real problem. How does not treating
trunk group as a URI parameter in a SIP URI cause any real-world
problems?

Frankly, I see this as the best proposal on the table at the moment.

I appreciate your taking the loose threads in this conversation
and tying them together. This should help us reach some degree
of consensus.

/a
_______________________________________________
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: [email-masked]
Date: Thu, 5 Sep 2002 14:17:37 EDT

In a message dated 9/4/02 7:21:45 PM Eastern Daylight Time, 
[email-masked] writes:

> SIP in general has no use for a concept of 'trunk groups';
> this is within the scope of telephony addressing, and belongs in the tel
> URL.
> 

[MAP] I'm further confused. If SIP has no use for the concept of 'trunk 
groups', why is this discussion going on?

I don't see that it is within the scope of "telephony addressing" either. I 
understand the tel:url to be intended to carry the telephone number. The 
current draft-antti-rfc2806bis-05.txt states that it is "for specifying the 
address of a terminal in the phone network". Isn't that what "tel" means? I 
suppose one could say that "tel" means "telephony" and that the header is 
intended to carry all the extraneous parameters associated with "telephony", 
but I din't think this was the accepted approach.

From a functional point of view, if a need to carry a trunk group identifier 
between entities really exists, it does not belong with the telephone number. 
I think we need to determine where such a thing "functionally" fits, not 
where it goes to keep the protocol pretty.

Mike Pierce
Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Sep 2002 14:58:08 -0500

Notes (on format standardization) inline.

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, September 05, 2002 8:00 AM
> To: Peterson, Jon
> Cc: SIPPING LIST; Cullen Jennings; Adam Roach
> Subject: Re: [Sipping] SUMMARY: Trunk groups in R-URI
> 
>
[snip] 
> > in the absence of any actually standard practices 
> > for TG formats that we would like to represent in SIP (that might 
> > populate the IANA registry mentioned below), there probably isn't any 
> > reason to go forward with this work. 
> 
> I am afraid I disagree.  Without some standardized manner of carrying
> trunk groups, a proxy from vendor A will not be able to inter-operate
> with gateways from vendors B, C, and D.  Currently, each gateway has
> its own manner of representing trunk groups -- some want them in the
> user portion of a R-URI, others want them as URI parameters; some want
> the name of the parameter to be 'tg', others want it to be
> 'trunk_group' -- it is a mess.
> 

Well, to be clear, I'm not saying that we need to invent some format for
TGs, install it in the draft and insist that it be used - we shouldn't be
kingmakers, and there are plenty of existing TG formats. First and foremost
I think the draft needs to provide a way for trunk group formats to be
standardized.

Two points about your argument above:

-  Just agreeing that 'tg' belongs in the tel URL of the Request-URI,
instead of belonging in some header, isn't going to suddenly make proxy A's
use of TGs interoperable with the use of TGs envisioned by gateway vendor B
if they don't agree on what the TG means - that was the point I was trying
to make. They would only interoperate if the trunk group identifier itself
were just an opaque string with no semantics (so that a proxy consults a big
table mapping disparate values like '0000001' and 'freds-trunk' to
destinations when it makes routing decisions). However, there are also ways
in which trunk group identifiers could be formatted in which the semantics
of the identifier contribute to the routing decision. For example, there is
at least one CLLI-based trunk identification format in use today, and CLLIs
contain legible geographic information that could even be parsed by a proxy
server and used to make a routing decision. If a proxy server just wants to
know whether it should relay this message to a proxy on the east coast or
the west coast, the geographic information could be used if the proxy
understood the TG format, and it would not require the TG to have some huge
table of mappings that treats every TG as a separate entry. So in other
words, we should not make architectural decision at this stage that assume
TGs must be opaque identifiers. And without understanding the format of the
information in a trunk group identifier, it is still not clear to me that a
given proxy vendor would be able to interoperate with a gateway made by some
other vendor. 

- If trunk groups have totally opaque and non-standard identifiers (like,
say, '23'), then there is a relatively high probability of collision between
how TGs are identified by different providers. In the SIPPING WG, we
generally do not assume that SIP signaling is ever restricted to some
intradomain environment (like a 'Trust Domain'). SIP signaling part of the
open Internet, and we should assume that message with a 'tg' value populated
by one provider could wander into someone else's network. We should take
steps to avoid any confusion that might arise because of this.

At a minimum, I think there needs to be a way to describe the format that is
being used for a trunk group identifier, and descriptions of the format need
to be standardized. If we have TG identifiers along the lines of:

tg=format-value

then the 'format' description can be registered with IANA. That way we will
minimize possible namespace collisions. It would be easy to understand that
the following were diffferent TGs:

tg=WCOMFMT-23
tg=ATTFMT-23

Now, the draft that defines the 'tg' parameter doesn't need to completely
populate this IANA registry, but I think it should pre-provision that
registry with at least one TG format value that is believed to be of value,
if for no other reason than to provide an example of how TG formats should
be registered.
_______________________________________________
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: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 6 Sep 2002 15:15:54 -0400

I really don't believe there is much one can do to standardize trunk group
identifier formats.  If I recall correctly, the location part of a CLLI is
12 characters long, but a complete trunk group identifier may be up to 20
characters long.  The extra eight characters won't conform to any standard.

I really think it should be handled as an opaque string.

> From: Peterson, Jon [mailto:[email-masked]] 
> Sent: Thursday, September 05, 2002 3:58 PM
> To: 'Vijay K. Gurbani'
> Subject: RE: [Sipping] SUMMARY: Trunk groups in R-URI
> 
> 
> 
> Well, to be clear, I'm not saying that we need to invent some 
> format for TGs, install it in the draft and insist that it be 
> used - we shouldn't be kingmakers, and there are plenty of 
> existing TG formats. First and foremost I think the draft 
> needs to provide a way for trunk group formats to be standardized.
> 
> -  Just agreeing that 'tg' belongs in the tel URL of the 
> Request-URI, instead of belonging in some header, isn't going 
> to suddenly make proxy A's use of TGs interoperable with the 
> use of TGs envisioned by gateway vendor B if they don't agree 
> on what the TG means - that was the point I was trying to 
> make. They would only interoperate if the trunk group 
> identifier itself were just an opaque string with no 
> semantics (so that a proxy consults a big table mapping 
> disparate values like '0000001' and 'freds-trunk' to 
> destinations when it makes routing decisions). However, there 
> are also ways in which trunk group identifiers could be 
> formatted in which the semantics of the identifier contribute 
> to the routing decision. For example, there is at least one 
> CLLI-based trunk identification format in use today, and 
> CLLIs contain legible geographic information that could even 
> be parsed by a proxy server and used to make a routing 
> decision. If a proxy server just wants to know whether it 
> should relay this message to a proxy on the east coast or the 
> west coast, the geographic information could be used if the 
> proxy understood the TG format, and it would not require the 
> TG to have some huge table of mappings that treats every TG 
> as a separate entry. So in other words, we should not make 
> architectural decision at this stage that assume TGs must be 
> opaque identifiers. And without understanding the format of 
> the information in a trunk group identifier, it is still not 
> clear to me that a given proxy vendor would be able to 
> interoperate with a gateway made by some other vendor. 
> 
> - If trunk groups have totally opaque and non-standard 
> identifiers (like, say, '23'), then there is a relatively 
> high probability of collision between how TGs are identified 
> by different providers. In the SIPPING WG, we generally do 
> not assume that SIP signaling is ever restricted to some 
> intradomain environment (like a 'Trust Domain'). SIP 
> signaling part of the open Internet, and we should assume 
> that message with a 'tg' value populated by one provider 
> could wander into someone else's network. We should take 
> At a minimum, I think there needs to be a way to describe the 
> format that is being used for a trunk group identifier, and 
> descriptions of the format need to be standardized. If we 
> have TG identifiers along the lines of:
> 
> tg=format-value
> 
> then the 'format' description can be registered with IANA. 
> That way we will minimize possible namespace collisions. It 
> would be easy to understand that the following were diffferent TGs:
> 
> tg=WCOMFMT-23
> tg=ATTFMT-23
> 
> Now, the draft that defines the 'tg' parameter doesn't need 
> to completely populate this IANA registry, but I think it 
> should pre-provision that registry with at least one TG 
> format value that is believed to be of value, if for no other 
> reason than to provide an example of how TG formats should be 
> registered. _______________________________________________
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 6 Sep 2002 18:07:51 -0400

A few notes below.

Jon Peterson
NeuStar, Inc.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, September 06, 2002 12:48 PM
> To: Peterson, Jon
> Cc: [email-masked]'
> Subject: Re: FW: [Sipping] SUMMARY: Trunk groups in R-URI
> 
> 
> inline.
> 
> Peterson, Jon wrote:
> 
> > destinations when it makes routing decisions).
> 
> I'll note that this model is generally consistent with the way the user 
> part of the request URI works. Its semantics are only understood by the 
> authority on the host portion of the URI.
> 

But of course, the tel URL could appear in the Request-URI without a host
portion (i.e. not as a part of a SIP URI).

[snip]
> 
> I think this is the main point of debate. We need to decide now whether 
> or not the trunk group is an opaque identifier, much like the user part 
> of the URI, or whether it has a standardized structure with well defined 
> meanings.
> 

My proposal is that we not close the door on the TG identifier being
something other than an opaque identifier. Presumably, my IANA registration
proposal would allow various operators to use the trunk group conventions of
their choice. Whether or not this entails that they deploy proxy servers
that use unconventional routing logic to interpret the Request-URI is their
own problem, one would think.

[snip]
> > how TGs are identified by different providers.
> 
> Thats fine, no?
> 

I think it could be somewhat problematic, though not totally defeating. If
trunk group identifiers are globally unique, I'm more comfortable with their
usage on the open Internet. If they aren't globally unique, then providers
that respect them will need to use network edge policies to remove TG
identifiers when they are represent in requests traversing the boundaries of
their administrative domain, etc.

> > In the SIPPING WG, we
> So long as its scoped by the host portion of the URI, I don't see the 
> problem.

Again, a problem if there is no host portion.

> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

---

From: Al Varney <[email-masked]>
Date: Sun, 08 Sep 2002 22:52:36 -0500

Jon,

    You and Jonathan seem to be moving towards a conclusion on this, but I 
thought some historical information regarding trunk groups might be useful 
before you conclude the work.

    1) While trunk groups (TGs) and individual circuits have some 
regionally-standardized identifiers in use, these are almost exclusively 
used in administrative systems and in maintenance of the physical 
facilities making up the circuits between switching nodes 
(exchanges).  Internally, exchanges almost exclusively use a number to 
represent a specific TG.

    2) The TG number at node A is unrelated to the TG number by which node 
B identifies the same TG (unlike the ISUP CIC [circuit identification 
code], which must be the same at both node A and B).  And since exchanges 
are re-arranged over time, the TG numbers may occasionally change.  This 
leads to a desire to minimize the number of places that know node A's TG 
numbers.  In particular, it is rare for an exchange or call-routing system 
to know the TG numbers of other exchanges.

    3) The desire to control call-routing outside an exchange is not new 
with SIP.  The "Intelligent Network" (IN, called AIN in the USA) uses 
query/response messaging at a centralized database to direct calls over 
specific TGs within an exchange.  Since an outgoing TG may be 100% 
occupied, some AIN messaging allows an ordered list of up to 3 
TGs.  Alternatively, the AIN "TG" may be interpreted as a routing index, 
relating an "AIN TG number" to a specific ordered set of TGs within a 
specific exchange.  This has the advantage that the same "AIN TG number" 
can be assigned in multiple exchanges, simplifying the administration of 
the centralized database AND the exchanges.

    4) Some sample USA applications of TG numbers:
      a) Billing records record a TG number as a decimal number between 0 
and 9999.
      b) AIN uses a Trunk Group number between 0 and 9999,
         but supports a "route index" of 8 digits.
      c) ANSI ISUP signals an Outgoing Trunk Group number (6 digits)
         in the EXIT message.

    5) While it might appear that SIP itself has no need for TG numbers, 
the BICC protocol (Q.1902) added an explicit Inter-nodal Traffic Group 
parameter to the evolved ISUP used by BICC.  BICC uses a packet network as 
a replacement for the explicit CIC/circuits of ISUP, and thus lost the 
ability to associate an incoming IAM with a trunk group.  The BICC Traffic 
Group parameter (variable length binary field) can be used between nodes to 
effectively differentiate one call from another, when there is no suitable 
means of signaling a desired differentiation between nodes.

    I don't really have an opinion about how SIP represents trunk groups, 
but it seems reasonable that the "destination TG" might want to be 
decoupled from the internal TG representation used by a gateway 
itself.  This would allow a single "tg=" parameter to select an ordered 
list of TGs within the gateway.

    Is it possible that a proxy might wish to know the actual TG or circuit 
selected by an outgoing gateway (for call records or troubleshooting)?  If 
so, then this might be added to some backwards SIP messages.

Al Varney

At 06:41 PM 9/4/02 -0400, Peterson, Jon wrote:

>I have a few comments on this plan of action.
>
>First, I think rendering the TG parameter as a SIP URI parameter instead of
>a tel URL parameter would be a mistake. There is no 'problem' with tel URL
>parameters appearing in the user portion of a SIP URI. The statement that
>this will not be semantically treated like a parameter does not mean
>anything to me. SIP in general has no use for a concept of 'trunk groups';
>Second, I think that in the absence of any actually standard practices for
>TG formats that we would like to represent in SIP (that might populate the
>IANA registry mentioned below), there probably isn't any reason to go
>forward with this work. We have enough work to do solving more substantial
>problems. I think finding some formats that merit standardization is a
>prerequisite for this work. I asked the list of anybody knew of any public
>TG format standards which were of interest in this work, and so far there
>hasn't been any response.
>
>Third, I'd like to suggest that some text for a draft on trunk groups in SIP
>could be lifted from my TRIP gwreg-arch document. In particular, section 2
>has definitions of TGs that came out of our discussion in the IPTEL WG.
>Section 3 has an architectural diagram that could be useful in that it
>illustrates the relationship between TGs and GWs, though the second half of
>the section is pretty specific to gwreg. Sections 4 and 5 contain some text
>that motivates the use of TGs by an element like a proxy server to route
>calls. I really don't have much motivation to push that draft forward now
>that the TRIP-GW discussions have more or less concluded... so the document
>might as well be cannibalized.
>
>Fourth, I have a long list of requirements for representing TGs in SIP that
>I would be happy to give to whomever wants to do this draft.
>
>Finally, please don't call the parameter 'dtg'. :) Call it 'tg'. That way it
>could at least be used to represent either DTG or OTG (per your 'suggestion'
>3 below, which I think is a valid requirement) depending on the context in
>which the URI appears.
>
>Jon Peterson
>NeuStar, Inc.
>
> > Sent: Wednesday, September 04, 2002 2:26 PM
> > To: SIPPING LIST
> > Cc: Cullen Jennings; Adam Roach; Vijay Gurbani
> > Subject: [Sipping] SUMMARY: Trunk groups in R-URI
> >
> >
> > Folks:
> >
> > Now that things have quieted down on this thread...
> >
> > form: sip:[email-masked];dtg=23, the only thing to be
> > The reasons for standardizing parameter name were (I realize that
> > these are not requirements, but maybe we can tease out the
> > requirements from these statements):
> >
> >       1/ Trunk group labels are private to the gateway and
> > should not be
> >          propogated too far into the network.
> >       2/ Works well with TRIP-GW (draft-ietf-iptel-trip-gw-00.txt),
> >          where-in TRIP will be used to update a LS with latest trunk
> >          group availability.  The LS (or proxy accessing the location
> >          information) can then turn around and indicate the selected
> >          trunk group to the egress gateway.
> >       3/ The trunk group label itself can be arbitrary since
> > it is owned
> >          by the PSTN switch the gateways connect to.
> >       4/ Trunk groups are traffic engineered entities, their loads and
> >          availability may change dynamically.
> >       5/ Much simpler and more interoperable to standardize
> > URI parameter
> >          name (alleviates DNS provisioning for proxies/UAs, alleviates
> >          standardizing names of trunk groups).
> >
> > Other set of suggestions that came up in context of this discussion
> > were:
> >
> >           heirarchical representations.  Furthermore, trunk groups can
> >           be managed as traffic engineered entities, with their loads
> >           changing dynamically in response to the calls presented at
> >           the gateway.  In such cases, it will be hard to synchronize
> >           DNS with the load fluctuation.
> >        3/ Carrying ingress trunk group information as well (from the
> >           gateway to the proxy to allow the latter to make routing
> >           decisions based on the ingress trunk group.
> >        4/ Having a parameter for the Carrier Identification
> > Code (CIC);
> >           I am afraid that <draft-yu-tel-url-05.txt> already attempts
> >           to standardize carrying a CIC in a tel URI.  When that tel
> >           URI gets transformed to a SIP URI, the CIC information will
> >           be contained in the userinfo portion of the SIP
> > URI.  Having a
> >           SIP URI parameter would be duplicating information.
> >        5/ Impose some order on trunk group names.  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.
> >
> > I hope I haven't missed (or inadverdently added/transposed/mis-
> > interpreted) anything during summarizing; if so, please let
> > me know.  If
> > this appears to be an accurate summary and a rough consensus on this
> > issue, I can (along with Cullen Jennings and Adam Roach) take
> > a stab on
> > an I-D towards this for further discussions on the list.
> >
> > Thanks,
> >
> > - 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: "Mark Watson" <[email-masked]>
Date: Tue, 10 Sep 2002 10:35:39 +0100

Al,

> means of signaling a desired differentiation between nodes.

If I remember rightly, BICC has in fact three parameters:

a) A Traffic Group Identifier, that you mention above
b) A Destination Trunk Group Identifier
c) An Originating Trunk Group Identifier

I'm not sure I've got the names 100% right.

(a) identifies a 'Trunk Group' between two BICC exchanges (i.e. *within* the
packet network). Of course this 'Trunk Group' is no longer a physical
facility, but a logical concept (renamed 'Traffic Group'). A Trunk Group in
the TDM network is a combination of a physical facility, and a set of
configured data at each exchange which specifies certain parameters used in
the processing of calls arriving/leaving on that facility. This concept of a
'configuration parameter set' can exist for a 'logical facility' just as
well, and this is what a Traffic Group is. Of course the configured
parameters here are implementation dependent.

I think this is quite different from the 'tg' URI parameter we are
discussing.

(b) is used by a BICC node (A) to indicate to a succeeding BICC->ISUP
gateway (B) that the call should leave the gateway (B) on a particular TDM
Trunk Group. This means A needs to have knowledge of the (names of) the
physical facilities on B - or at least some representation of them.

(c) is used by a ISUP->BICC gateway (C) to indicate to a succeeding BICC
node (D) that the call arrived on a particular TDM Trunk Group. Again, this
means D needs to understand the Trunk Group names used at C.

I understand that the proposed URI parameter fulfils the same role as (b)
and (c).

Regards,

Mark

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 12 Sep 2002 13:19:05 -0400

Some notes below.

Jon Peterson
NeuStar, Inc.

> From: Al Varney [mailto:[email-masked]]
> Sent: Monday, September 09, 2002 2:54 PM
> To: [email-masked]
> At 04:09 PM 9/9/02 -0400, Michael Hammer wrote:
> >Jon,
> >
> >The problem with your point number two is that, to date, the discussion 
> >has suggested that the TG usage would occur ONLY within the domain of a 
> >single administration.
> 
> >Mike
> 
> 
> Mike,
>    My prior "history" message on this topic probably failed to clarify 
> that, in current circuit switched networks, TG numbers are almost 
> exclusively used within a single administrative domain.  ITU-T and ANSI T1

> committees, nonetheless, have standardized parameters in ISUP, BICC and 
> AIN/TCAP that carry those numbers -- even though they are unlikely to
cross 
> administrative domains.
> 
>    It would seem that the current effort to introduce "tg=" into SIP 
> springs at least partially from the same reasoning that caused TGs to be 
> added to the AIN protocol -- control of a switching point by a remote 
> "routing control" node.  At least that's how the proxy-to-ISUP-gateway 
> usage appears to me.
> 

Exactly. There have been some proposed applications in which an SCP-like
redirect server would assemble an ordered list of destination trunk groups
that would serve as routing alternatives for a call. It is possible that
such a redirect server could be consulted by multiple administrative domains
- which does assume that the convention used to identify a particular trunk
group is meaningful to the separate domains. There is at least one
application I know of where this actually makes a lot of sense.

I'm also mildly concerned that the usage of 'tg=' identifiers to express an
originating trunk group might cross administrative boundaries (in a Contact
header, for example). Naming collisions might be important here; it's
possible that 'tg=23' could inadvertantly identify different resources in
different networks, which could lead to confusion. While one might create
policies at the edges of networks to weed out the 'tg=' parameter, being
explicit about the convention used to identify a trunk group by segmenting
the namespace would also help significantly.

>    I don't know if the standardization of intra-domain parameters is an 
> issue for IETF.  If so, there must at least be some standardized means of 
> extending protocols for such private parameters.  Maybe "tg=" falls in
that 
> category?

We do have such a concept, yes, of defining private headers (or "P-"
headers, as they are affectionately known). But that's kind of a path of
last resort, and I don't think there's really disagreement about having a
'tg=' parameter at all - the controversial point seems to be the degree to
which we should specify the conventions for trunk group identifiers.

> Al Varney
> 
> >At 02:58 PM 9/5/2002 -0500, Peterson, Jon wrote:
> >
> Request-URI,
> identifiers (like,
> signaling part of the
> That way we will
> to completely

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 13 Sep 2002 06:45:57 +0200

Hi all,
I'm a little bit puzzled about the discussion (but I didn't follow the whole discussion this week, therefore sorry if I double comments) regarding the TG within the R-URI. Did you thought on that fact that the TG is not an unique identifier (I think you discussed this). But I have the problem if I have a SIP network with 50 Interworking Gateways and every GW uses the same semantic for naming TG (that is usual). What effort you have receiving this TG if you not know to which GW it belongs. 
Therefore the TG is only useful if you know exactly where it comes from.

From my point of view it could be useful to have such kind of indication within SIP but I would also like to see some further values that makes that TG unique like the OPC of the TG.

If you start with extending SIP with ISUP/PSTN related information, I can think on much more that you can put into SIP from the Operator point of view .... :-).

Regarding the Inter-nodal Traffic Group Identifier that was introduced within BICC CS2. You can find the definition within the specifications Q.1912.X.

regarding the procedures Q.1912.4 is stating:

8.16	Inter-nodal traffic group identification
The Inter-nodal Traffic Group Identifier parameter may be included in the IAM in order to enable classification of calls between adjacent nodes. It identifies the logical traffic group to which the call belongs, i.e. this identifier is of significance only between two adjacent CSFs. These classifications could, for example, be used to make a distinction between different service sets. These classifications are not standardized.

8.16.1	Sending Inter-nodal traffic group identification
If needed for the chosen outgoing route, the CSF shall include the Inter-nodal Traffic Group Identifier parameter, populated according to the relevant classification. This classification may depend on a classification received on the incoming side.
NOTE - The Parameter Compatibility Instruction Indicators for this parameter should be set to ensure that the parameter is not passed on at a node that does not recognize the parameter.

8.16.2	Receiving Inter-nodal traffic group identification
The traffic group identification received in a Inter-nodal Traffic Group Identifier parameter is used according to the relevant classification. A received Traffic Group Identifier parameter may be used to influence the routing of the call.

Roland

-----Ursprüngliche Nachricht-----
Von: Peterson, Jon [mailto:[email-masked]]
Gesendet: Donnerstag, 12. September 2002 12:19
An: 'Al Varney'; [email-masked]
Betreff: RE: [Sipping] SUMMARY: Trunk groups in R-URI

Some notes below.

Jon Peterson
NeuStar, Inc.

cross 

that