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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Sep 2002 16:33:46 -0500

[Resending this, I didn't see it go through on the SIPPING list...]

Notes (on format standardization) inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> 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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Sep 2002 15:47:55 -0400

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.

> However, there are also ways
> TGs must be opaque identifiers. 

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.

And without understanding the format of the
> given proxy vendor would be able to interoperate with a gateway made by some

Sure there will be interop. It'll just be the same constraint we 
generally have for URIs. A proxy in one domain cannot interpret the user 
part of a URI that is owned by another domain.

> how TGs are identified by different providers.

Thats fine, no?

> In the SIPPING WG, we

So long as its scoped by the host portion of the URI, I don't see the 
problem.

-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