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

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 4 Sep 2002 18:41:18 -0400

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';
this is within the scope of telephony addressing, and belongs in the tel
URL.

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.

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> 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...
> 
> 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, the only thing to be
> standardized will be the parameter name 'dtg', NOT the trunk 
> group label
> '23').
> 
> 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:
> 
>        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.  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.
>        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.
>        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
> 
> _______________________________________________
> 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: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 05 Sep 2002 10:00:21 -0500

Peterson, Jon wrote:
> First, I think rendering the TG parameter as a SIP URI parameter instead 
> of a tel URL parameter would be a mistake. 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.

That is fine; I am not opposed to making it a tel URI parameter.

> There is no 'problem' with tel URL
> anything to me. 

Philosophically, I disklike representing what are actually parameters in
the user portion of the SIP URI, even though rfc3261 BNF allows it
(rfc2543 BNF did not).  A tel URI of the form:

    tel:+16302240216;tg=44

will get represented as a SIP URI of the form:

    sip:+16302240216;tg=[email-masked];user=phone

So, what was an actual parameter in a tel URI (tg) is now simply an
unparsed literal in the user portion of the SIP URI.  The SIP entity
that wants to use this information to affect routing will have to
further parse it.

Since rfc3261 supports the 'other-param' production rule (rfc2543 did
not) for R-URIs, we could just as easily have "tg=44" be part of that
rule.  I am not suggesting we do this now (it is too late, anyway).
Just a nit.

That is what I meant by a tel URI parameter not being semantically
represented as a parameter in a SIP URI.

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

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.

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

My instinctive feeling is that we should not attempt to standardize the
formats of the trunk group label.  If we take the position that naming
the trunk groups is a matter of local policy, then why the need to
standardize them.  They only hold significance for a proxy fronting
a gateway (or a MGC controlling the gateways).

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

Absolutely.  There is enough work done in there to use as a starting
point for any other work going forward.

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

Sure; unless there is a need to carry the dtg and otg at the same time,
which at least now, I do not forsee.

Thanks,

- vijay