Subject: [Iptel] Comments on trunk group draft

From: [email-masked]
Date: Thu, 15 Jan 2004 14:19:31 EST

Comments on draft-ietf-iptel-trunk groups-01

General:

As defined in the draft for tel:uri, the tel:uri is used to describe 
resources identifed by telephone numbers. Trunk groups can not be identified by 
telephone numbers, so this requirement for a standardized way to identify trunk 
groups should not be met by an extension to the tel:uri. (The logic in Section 4.1 
Req 1 is flawed.)

Section 4.2 states that "trunk groups have a meaning only within an 
administrative domain (i.e., local scope)". This is not true in the general sense. If 
it were, there would be no need for standard naming schemes, since each domain 
could make up their own. In fact, trunks can interconnect switches in 
different adminstrative domains, hence the need for standards.

For the purpose of this draft (proxy to GW), the trunk group identities have 
meaning only within an administrative domian only if it could be assumed that 
the proxy and GW are part of the same administrative domain. If, in fact, a GW 
could be controlled by different proxies in different domains, then the trunk 
group identity scheme is determined by the GW and all proxies with which it 
communicates must comply with that naming scheme. There is no ambiguity or 
"global" reach. Uniqueness exists for each GW.

This issue of standardized naming of trunk groups has been addressed by other 
standards bodies (ITU-T and T1 in the US.) The IETF does not need to define 
yet another system, but should limit itself to defining a local identity which 
can be included in SIP messages (or whatever messages might be used between a 
SIP proxy and a VoIP Gateway).

If one looks at the architecture for interfacing a SIP proxy, through a GW, 
to a PSTN switch (CO), we have:

 -----         -----                         -----
|     |   a   |     |           b           |     |
|Proxy|---/---| GW  |-----------/-----------| CO  |
|     |       |     |                       |     |
 -----         -----                         -----

We should assume that there is already a standardized way to identify trunk 
groups (and trunks) across interface "b". For the interface at "a", one of two 
methods can be used:

1. Use the existing standardized naming from "b" To simplify administrative 
tasks, this would be better, but not required.
2. Use a local definition, which only has significance between the proxy and 
the one GW

The requirement in this draft should be to support both cases.

The "Phone-context" parameter caused seemingly endless discussions with the 
tel:uri and will probably do so here. I have no idea what function it serves 
across interface "a" in the above. If interface "a" were to use the same 
standardized scheme as used at "b", there is no such thing as "phone context". If it 
is to use a local scheme, then it seems that it only needs to carry an 
arbitrary strings of characters for the "trunk group name", like "tg55" in the 
example. Nothing more, since, by definition, it only has a meaning within that one 
GW, that is, no global significance. (The logic in Section 4.2 is flawed.)

The example in Section 6 uses "phone-context=+1-555-555". It is unknown what 
this partial E.164 number could represent.

Specific comments:

In several places throughout the text, the reference to "trunk group" should 
read "identity of the trunk group" or similar wording. For example:

Section 2, first sentence and in Bullet item 1.
Last sentence of Section 5

Section 3, second paragraph:

The statement about calling a bundle of DS0s a "trunk" only adds confusion 
and is probably incorrect. This statement should be deleted.

Section 4.3

It is unclear why it would ever be necessary to include both originating and 
terminating trunk group (in a SIP message). As shown in 7.1 and 7.2, one is 
needed for an "outgoing" call and the other is needed for an "incoming" call. 
They may appear in different places for these two cases, but never both 
concurrently.

The second paragraph states that "routing entities can make informed routing 
decisions based on either the orginating or the terminating trunk groups". 
Since the purpose of routing is to determine the terminating trunk group, the 
decision can't be based on the terminating trunk group.

Section 4.4

In the fourth paragraph, the references to "UAS" should be "egress Gatway".
In the fifth paragaph, the reference to "UAC" should be ingress Gateway".

Although strictly speaking, the Gateway serves as a "UAS" and "UAC", the term 
"Gateway" here would match the same use of the term in other places such as 
the examples in Sections 71. and 7.2. (The "UAC" shown in 7.2 does not include 
the trunk group identifty as implied by the current text in the fifth 
paragraph.)

Section 7.1

The application that seems to be supported in this example is one in which 
the Proxy needs to know the trunk group on which the call came from the PSTN, 
since this often affects the dialing plan, or other handling of the call. But 
doesn't it also need to know which trunk in the group it is on, for example, to 
keep track of resources?

Section 7.2

The application that seems to be supported in this example could be one of 
the following:

1. The Proxy selects the GW and trunk group to use to send a call to the 
PSTN, but leaves it up to the GW to select a trunk within that trunk group.
2. The Proxy selects the actual trunk group and trunk to use.

In case 1, there should be a response from the GW back to the proxy to 
identify which trunk was used.
In case 2, the INVITE needs to include an identity of the trunk.

Mike Pierce
Artel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 21 Jan 2004 11:07:39 -0600

> Comments on draft-ietf-iptel-trunk groups-01

Mike:

Thanks for your comments.  Responses inline.

> resources identifed by telephone numbers. Trunk groups can not be 
> identified by telephone numbers, so this requirement for a standardized 
> way to identify trunk groups should not be met by an extension to the 
> tel:uri. (The logic in Section 4.1 Req 1 is flawed.)

Insofar as the tel URI has been used to describe dial strings,
Calling Party Category (CPC) parameter, number portability and
freephone, I don't see the disadvantage of using it to describe
other telephony-related machinations like trunk groups.

> For the purpose of this draft (proxy to GW), the trunk group identities 
> have meaning only within an administrative domian only if it could be 
> assumed that the proxy and GW are part of the same administrative 
> domain. 

In the deployments I have seen, the gateway and the proxy are
owned by the same administrative domain.  The problem arises, of
course, if the gateway vendor and proxy vendor are different.  Then,
under the current rules of the game, some customization is needed
to make the proxy and the GW communicate the trunk group information.
We are simply attempting to avoid that customization.

> This issue of standardized naming of trunk groups has been addressed by 
> other standards bodies (ITU-T and T1 in the US.) The IETF does not need 
> to define yet another system, but should limit itself to defining a 
> local identity which can be included in SIP messages (or whatever 
> messages might be used between a SIP proxy and a VoIP Gateway).

Agreed; we made a decision long time ago -- the emails I have for this
I-D date back to August 2002 -- specifically to not standardize
the names of the trunk groups.  Other bodies do it well.  All we
are interested in is, as mentioned above, standardize the mechanism
by which this name is communicated between the GW and proxy.

> If one looks at the architecture for interfacing a SIP proxy, through a 
> GW, to a PSTN switch (CO), we have:
> 
> 
> -----         -----                         -----
> |     |   a   |     |           b           |     |
> We should assume that there is already a standardized way to identify 
> trunk groups (and trunks) across interface "b". For the interface at 
> "a", one of two methods can be used:
> 
> 1. Use the existing standardized naming from "b" To simplify 
> administrative tasks, this would be better, but not required.
> 2. Use a local definition, which only has significance between the proxy 
> and the one GW
> 

I believe that they do.  The I-D does not make any assumption
about the representation of the token that follow tgrp= parameter.
They could be the trunk names from "b" or locally significant names.

> The "Phone-context" parameter caused seemingly endless 
> discussions with the tel:uri and will probably do so here. I have no 
> idea what function it serves across interface "a" in the above.

It probably serves little, if any, function in interface "a"; but
if it could serve a purpose if a proxy P1 sends a request to another
proxy P2 in a different domain using trunk groups pertinent to
P2's domain.  How P1 knows about these trunk groups is outside the
scope of this I-D.  I can add some of this discussion in the I-D if it
will help.

> The example in Section 6 uses "phone-context=+1-555-555". It is unknown 
> what this partial E.164 number could represent.

Sorry; my mistake -- the number needs one more digit.  I'll fix it.

> Specific comments:
> 
> In several places throughout the text, the reference to "trunk group" 
> should read "identity of the trunk group" or similar wording. For example:
> 

Sounds reasonable.  Will change.

> Section 4.3
> 
> It is unclear why it would ever be necessary to include both originating 
> and terminating trunk group (in a SIP message). As shown in 7.1 and 7.2, 
> one is needed for an "outgoing" call and the other is needed for an 
> "incoming" call. They may appear in different places for these two 
> cases, but never both concurrently.

This is a result of agreements on the mailing list long time ago
where there was forseen a need to represent both the terminating
and originating trunk groups.  Section 4.3 imposes a SHOULD
strength, so it is not mandatory; but the convention does allow
for it.

> The second paragraph states that "routing entities can make informed 
> routing decisions based on either the orginating or the terminating 
> trunk groups". Since the purpose of routing is to determine the 
> terminating trunk group, the decision can't be based on the terminating 
> trunk group.

Agreed, but some other intermediary between the proxy that chose
the terminating trunk group and the GW may prioritize requests
coming into it with a certain trunk group.  Admittedly, I do not
have a specific scenario in mind right now.  Having the above
sentence doesn't hinder us in any shape or form.  So, I am
leaning more towards leaving it in for the sake of generality.

> In the fifth paragaph, the reference to "UAC" should be ingress Gateway".

Sure; will change.

> Although strictly speaking, the Gateway serves as a "UAS" and "UAC", the 
> term "Gateway" here would match the same use of the term in other places 
> such as the examples in Sections 71. and 7.2. (The "UAC" shown in 7.2 
> does not include the trunk group identifty as implied by the current 
> text in the fifth paragraph.)

Ah, that may be my failing.  the UAC in the figure in Section 7.2
is supposed to be a native SIP UAC.  It is starting a session
which ends up on the PSTN.  Hence, the invitation from it to
the proxy (labeled "Call Request") will not contain any trunk
group information.  The signaling between the proxy and the
egress gateway does contain trunk group information.

I will re-word this in the I-D to make this more specific.

> Section 7.1
> 
> The application that seems to be supported in this example is one in 
> which the Proxy needs to know the trunk group on which the call came 
> from the PSTN, since this often affects the dialing plan, or other 
> handling of the call. But doesn't it also need to know which trunk in 
> the group it is on, for example, to keep track of resources?

Sure; but that will be outside of the scope of this particular
I-D.

> Section 7.2
> 
> The application that seems to be supported in this example could be one 
> of the following:
> 

Hmmm -- how deeply do we want to wade in the water?  The assumptions,
thus far, have been that we are interested in representing trunk
groups, not individual trunks themselves.  I note that TGREP also
works on trunk groups as an atomic unit.  Drilling down further
can be accomplished by having naming conventions to the trunk-
group parameter, but these will be outside the scope of this I-D.

Thanks for the comments, Mike.

- 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

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel