Subject: [Iptel] Is trunk group a new namespace?

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 13 Jan 2005 17:06:44 -0600

Folks,

In order to close the last open issue with trunk-group, I had
a series of email exchanges with the WG chairs, the
results of which now need to go before the WG to decide how to
move forward.

The last open issue was how to resolve the case where an
incoming call request does not have a calling party's number
available.  How do we indicate the originating trunk group?

We had almost reached a solution in the form of the following
URI: Contact: <sip:telurifmt;tgrp=[email-masked]> (the
I-D exhorts originating trunk groups to go in the Contact
header).

In the email exchange with the WG chairs, Jonathan has
suggested a couple of issues: first, the fact that a trunk
group can exist without a phone number appears to imply that
it is cannot be associated with a tel URI and may, in fact,
indicate that this is a new resource complete with its
own scheme.  Something like:

    trgrp:trunk-group-id[:phone-number]@domain

Second, saving the originating trunk group in the Contact
header is not semantically correct; if the originating trunk
group is to be used for routing, then Contact is not the
semantically correct header to save this information in.

Here is my take on these issues.  The second one is easier
to tackle, so let me try that first.  Jonathan is accurate
in pointing out the semantic use of Contact header.  How-
ever, we reached a decision long time ago in the life of
the trunk-group I-D that we would like NOT to have parameters
like ;o-tgrp=xxx;t-tgrp=yyy in the R-URI.  Hence we
decided to put the originating trunk group in the Contact
header with the understanding that when it is used for
routing in the reverse side, it will appear in the R-URI
position.  But what if it is used in routing on the initiating
side?

The first issue -- trunk-group being a new resource --
is an interesting one.  It has ramificiations, if we decide
to go that route.  Where will it appear?  In a new header(s)?
as parameters to the R-URI or the Contact URI?  We will need
a short paragraph on how to convert trgrp URIs to sip URIs
or tell URIs, ...

So, we have some choices to make:

Regarding putting originating trunk group information: do we
want to leave it in the Contact header or find a new place
for it?

Regarding representing trunk group information itself: do we
want hash out more abstractly the relationship between the
trunk group and the phone number from a namespace prespective?

To make matters worse, I will point out that we already have
a few implementations that are following
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt.
So depending on what we decide, the implementations will be impacted.

Opinions and comments welcome.

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

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

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 16 Jan 2005 14:42:19 -1000

inline comments - not as chair..

Summary - I am very against the new URI type idea. It is not deployable -
more inline

> I-D exhorts originating trunk groups to go in the Contact

I don't like the making up telurifmt as a special SIP user name. However,
what the user port of a contact is is a GW local issue and not defined by
SIP. The GW could put line1 or ds0-22 or a random number. This problem only
comes up in the context of what originating information that is currently in
the contact header.
 
>     trgrp:trunk-group-id[:phone-number]@domain

The trunk group without a phone number would clearly be useless as a
destination. As a GW source information, I'm not keen on it. Were would you
put it? In the Contact header? You would have to map it to a sip URI to do
this which would result in a SIP uri in the contact that looks almost
identical to what everyone has already implemented. This would be a huge
amount of work that in the end resulted in protocol on the wire that was
semantically identical and differed by at most a few bits in syntax.

I am really against the new URI type idea - many SIP elements support tel
and the current proposal works in a backwards compatible way with all those
devices. If we make a new trgrp URI, no proxy or UA will know about it or be
able to do anything with it. There is no migration path from tel to trgrp
until they are all replaced. No one will every do it because they are
already using tel. 

> semantically correct header to save this information in.

I'm not sure I agree with this. The Contact identifies the resource on the
UA. The trunk group is part of the resource name on the GW. Saying you can
only route on things in the request URI it totally bogus. I'll point at CPL
for example. It is fine to route on many things in the SIP message. The
contact header, as used in a registration if pretty fundamental to how
requests get routed in SIP. GRU is going to work because some elements are
going to look at tag in the contact and route based on them.

> want to leave it in the Contact header or find a new place

I view the originating trunk group as part of the name of the resource on
the GW and thus reasonable to put in the contact.

> Opinions and comments welcome.

If someone can point out the harm that results in trunk group being a
parameter of a tel URI that would be fixed by having a separate namespace, I
would probably change my opinion.

> - vijay

Part of this discussion was brought up by the example of an IAM with no
originating phone number but where the GW still sends an INVITE. In this
case SIP does nto say what to put in the From but this is a SIP/tel problem
not a trunk group problem.

My proposal .... More or less keep what we have and

Allow a trgp and phone-context parameter in a tel URI.

Also allows these is a SIP uri even if that SIP URI is not mapable to a
valid tel URI

When this is seen in a contact, it identifies the PSTN associated resource
on the GW identified by the contact header

When this is seen in a request URI, it specifies the desired trunk group for
reaching the PSTN resource identified in the request URI

We have been discussing this for a long long time as a WG item. Unless
someone has some specific harm or problem caused by the proposed solutions,
I'm not keen on totally throwing it out.

PS - I'm sick and can't think straight - I lost my crypto token and can't
run my VPN so can't do email so have no idea when I will send this or
receive responses. I reserve the option to claim my evil twin skip wrote
this and I disagree with all of it :-) Someone convince me I'm nuts.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Jan 2005 20:18:49 -0500

Also not as chair.

I've considered this further, and concluded that here is a case where 
the pragmatic approach in the current draft is probably a better choice 
than the more theoretical considerations that led me to consider the 
idea of a new namespace.

As such, I agree with everything cullen suggests, but disagree on one 

 > Also allows these is a SIP uri even if that SIP URI is not mapable to a

I'd rather not do that. Instead, I'd rather declare this problem 
(indicating a trunk group without a phone number) as out of scope. This 
is not a tel URI issue at all - its an ISUP to SIP mapping issue. Our 
job is to define a way to extend the tel URI to be able to indicate 
trunk groups, and nothing more.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Jan 2005 10:03:35 -0600

> than the more theoretical considerations that led me to consider the 

Jonathan:

OK; pragmatism wins this one.

> trunk groups, and nothing more.

As I have so learnt in the past couple of weeks, the calling number
is optional in ISUP.  So, I would also agree that mapping an
absent ISUP parameter to a SIP element is an ISUP to SIP mapping
issue and outside the scopr of the trunk-group I-D.

I will consider this issue resolved, and will rev up the draft
with the WGLC and other discussions shortly.

Thanks,

- vijay

---

From: "Shan Lu" <[email-masked]>
Date: Fri, 21 Jan 2005 11:27:23 -0500

All,

First, I agree with the consensus that trunk group should not be a new
namespace.

More inline.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Jonathan Rosenberg
>Sent: Thursday, January 20, 2005 8:19 PM
>To: Cullen Jennings
>Cc: [email-masked]; Vijay K. Gurbani
>Subject: Re: [Iptel] Is trunk group a new namespace?

<snip>
>(indicating a trunk group without a phone number) as out of 
>scope. 

Declaring out of scope does not make the problem go away, does it? I would
further argue that not solving the problem would severely limit the
proposal's usability. Think of calls that requested privacy. A solution that
can fail on any given call is not a real solution.

But you have a point that the I-D went out of its way to address the
problem. The real issue, in my opinion, lies in RFC3966. Had 3966 allowed
tel uri to have empty phone digits (but meaningful parameters), we won't
have this discussion at all. As a side note, sip uri allows completely bogus
userinfo/hostport but valid uri parameters.

The proposal in the I-D may be ugly and the I-D may even be the wrong avenue
to address the issue. But that's what you get for not doing right at first
try in 3966. Not to mention it does solve a real issue.

Regards,

Shan Lu

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Jan 2005 10:36:16 -0600

Shan Lu wrote:
> Declaring out of scope does not make the problem go away, does it? 
> I would further argue that not solving the problem would severely 
> limit the proposal's usability. Think of calls that requested 
> privacy. A solution that can fail on any given call is not 
> a real solution.

Cullen, in an earlier email, wrote the following which I think is
worth bringing up:

    Now the problem came up when trying to overload where a call
    came from into the contact header field value. In this case
    people are trying to specify the trunk group but leave the
    telephone number unspecified. However, the contact identifies
    the GW (and the trunk group on GW) - it does not necessarily
    identify the PSTN endpoint that called the originating GW.
    The From would identify the originating endpoint on the PSTN.
    Keep in mind the calling party in the IAM gets mapped to the
    From not the contact header - it is a far end issue. The
    trunk group, which is a local to the GW issues, is what makes
    sense to map into the contact for the GW. A GW could form the
    user portion of the contact by just saying which DS0 was in
    use and adding the logical trunk group.

The last sentence above provides a decent way out to generate a
user portion and add the trunk-group parameters to it without
us having to mandate a certain user token.

- vijay

---

From: "Shan Lu" <[email-masked]>
Date: Fri, 21 Jan 2005 13:55:39 -0500

Vijay,

Is it the proposal to use the following:

Contact:<sip:1;tgrp=[email-masked]>, where DS0 number is 1 and TG is 2?

The why don't you use the same format even when calling number is available?
I have no issue with it, but don't call it tel-uri because it isn't.

Regards, 

Shan Lu
>On Behalf Of Vijay K. Gurbani
>Sent: Friday, January 21, 2005 11:36 AM
>To: Shan Lu
>Cc: [email-masked]; Cullen Jennings

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Jan 2005 14:21:11 -0600

> Contact:<sip:1;tgrp=[email-masked]>, where DS0 number is 1 and TG is 2?

Yes, something to that effect.  I will flesh it out further
in the rev'd I-D.

> The why don't you use the same format even when calling number 

The I-D, as it currently stands, is focused on where to place
the originating trunk group, not what the user part of the
Contact SIP URI should be.  If an implementation wants to
substitute something other than the calling party number (if
present), they can do so.  On the other hand, if the calling
party number is not present, the next rev of the I-D will
provide some guidelines on what to populate in the user part.

> I have no issue with it, but don't call it tel-uri because it isn't.

I like your "no issue with it" part ;-)

Thanks,

- vijay

---

From: [email-masked]
Date: Sat, 22 Jan 2005 00:19:05 -0500 (EST)

>From: Vijay K. Gurbani <[email-masked]>
>To: Shan Lu <[email-masked]>
>CC: [email-masked], Cullen Jennings <[email-masked]>
>Date: Jan 21, 2005 - 3:32pm

>Yes, something to that effect. I will flesh it out further

Wait. Doesn't this take a full circle back to our earlier discussion? I
thought we agreed upon the need for a keyword, such as "anonymous" or
"teluri", no?

Without such a keyword, how do you inform recipient of the above sip uri
that "tgrp" stands for "Trunk Group" and not "The Gourmet Roasted Pizza"?
Unless you think the DS0 number is sufficient.

Regards,

Shan Lu

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Jan 2005 00:11:09 -0500

Actually, I don't see why its needed to specify any kind of keyword at all.

Let us remember that we are talking about the contact header field. As 
Cullen has pointed out, it doesn't identify the originator but rather a 
port on a gateway. As such, just because there was no calling number 
doesn't mean one could not use a tel URI to identify the gateway line. 
Seems like something of the form:

tel:<lrn>;phone-context="<provider-domain>"

would suffice, in which case one could add a trunk group to this and 
then turn it into a sip uri:

sip:732766;phone-context=provider.com;tgrp=[email-masked];user=phone

I don't think that we need to say anything about how the tel URI is 
constructed, merely that any URI that is a reasonable descriptor for the 
gateway "port" resource itself will suffice.

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 22 Jan 2005 20:15:55 -0800

> with the WGLC and other discussions shortly.

This sounds like the best path forward to me. I'm happy with this.

Cullen - not as chair.

Actually as chair, after listening to all the options, I really think this
is the only path that has a good chance of closing this issues anytime in
next year to two. Given the WG desire to finish this work, I think this is
the best path forward with my chair hat on too :-)

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 23 Jan 2005 06:49:21 -0800

> userinfo/hostport but valid uri parameters.

Not as chair...

The issue with a tel URI with no telephone number is that the semantics of
what you do with are unclear. Imagine a HTTP URI with no host. What does it
mean? My personally view that is unless we explain to the IESG what it means
they are likely to tell we are doing the wrong thing and go invent a new URI
type - this is a long road.

It's true that for some problems, all you need is trunk group information. I
think this draft on trunk group attributes on a tel is not attempting to
solve that class of problems. Something else can be done to solve them.
However, having trunk group information attributes with a tel is useful for
some other problems and that is what this is well defined for.

---

From: "Shan Lu" <[email-masked]>
Date: Mon, 24 Jan 2005 11:40:44 -0500

Jonathan,

While I like the practical side of the proposal, two observations came to
mind:

1. It is not at all clear that contact header is limited to gateway "port"
resource. RFC3398 does not say so. The rest of the TG draft actually uses
contact to mean calling party tel-uri. I would venture to guess that most
existing ISUP gateways use contact header to indicate IAM calling party
attribute in some shape or form.

2. We now have created one precedence where a tel uri is only a tel uri in
syntax that is not intended to represent any real telephone resource. I
believe it is important that the TG draft say something on how such tel uri
can be formed in contact header. Further it must point out the possibility
that tel uri contained in contact header may not be a real tel uri.

BTW, I think it is even less likely to have calling exchange's LRN in IAM
(if I interpret your example correctly).

Regards,

Shan Lu       

>Sent: Sunday, January 23, 2005 12:11 AM
>To: [email-masked]
>Cc: [email-masked]; 'Vijay K. Gurbani'

---

From: "Shan Lu" <[email-masked]>
Date: Mon, 24 Jan 2005 11:58:00 -0500

Cullen,

Agreed - I wasn't suggesting the long road. Just wanted to have a tel uri
similar to sip:[email-masked]. For instance,
"tel:-;phone-context=internal" could be useful to indicate attributes of the
resource w/o having to reveal the number. But wasn't suggesting to modify
3966.

Regards,

Shan Lu

>On Behalf Of Cullen Jennings
>Sent: Sunday, January 23, 2005 9:49 AM
>To: Shan Lu; Jonathan Rosenberg