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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 04 Sep 2002 16:25:39 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Sep 2002 18:30:51 -0400

Vijay,

I remember the suggestions for a parameter on the tel: url, but don't remember that getting changed to a parameter on a sip url. Since this really only makes sense for telephone numbers, for which tel: urls are applicable, it makes more sense to me that this would also be a tel: parameter. 

You say this is a problem because, when transformed to a sip url, semantically it won't be treated as a parameter. But it would be transformed to a sip url with the user=phone parameter, which then defines the syntax and semantics of the user part as equivalent to a tel: url, so there is no problem. 

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Sep 2002 12:13:02 -0400

My own two cents on this inline.

> standardized will be the parameter name 'dtg', NOT the trunk group label

I agree with others who have argued that the parameter name should be 
"tg", and whether this is an originating or terminating trunk group is a 
matter of context. If a URI with this parameter appears in the From 
field, it means that the trunk is an originating trunk group, request 
URI would mean terminating.

More below.

>          subsequently, a transformed SIP) URI.

I think trunk group is clearly a tel URI parameter, and as a result, 
will be transformed into a component of the user part of the SIP URI 
based on the rules in RFC 3261. This is how things like cic will get 
transformed into SIP URLs, and I see no reason to make trunk group an 
exception.

>          provide at least one or two common and useful formats in the

I remain agnostic on this. Generally, if someone else already has 
specified a naming convention with trunk groups, we should use that and 
not invent our own. I do not know if that is the case or not.

-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