Subject: [Iptel] getting group consensus on moving forward with our work items

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Nov 2004 16:03:24 -0500

Folks,

At the iptel meeting today, there was consensus in the room on plans for 
moving forward with various drafts. I'd like to verify that consensus by 
asking the list if folks are OK proceeding with the following:

* Proceed to wglc on draft-ietf-iptel-tel-np once a revision appears in 
the archives

* Proceed to wglc on 
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt 
immediately following the ietf

* adopt 
http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt 
as a work item of iptel

* do not adopt 
http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt 
as a work item. The author will take it directly to IESG as an 
individual draft.

* do not adopt the expired tel cpc draft 
(http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a 
work item. If folks have a problem that they believe is addressed by 
this work, please bring that forward in the next few weeks.

* tgrep will go to IESG after a revision incorporating comments from 
Cullen and the pending comments from Jonathan

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

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

---

From: David R Oran <[email-masked]>
Date: Tue, 9 Nov 2004 17:25:29 -0500

i am fine with all these proposed actions.
Dave.

On Nov 9, 2004, at 4:03 PM, Jonathan Rosenberg wrote:

> Folks,
>
> At the iptel meeting today, there was consensus in the room on plans  
> for moving forward with various drafts. I'd like to verify that  
> consensus by asking the list if folks are OK proceeding with the  
> following:
>
> * Proceed to wglc on draft-ietf-iptel-tel-np once a revision appears  
> in the archives
>
> * Proceed to wglc on  
> http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group 
> -02.txt immediately following the ietf
>
> * adopt  
> http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi 
> -00.txt as a work item of iptel
>
> * do not adopt  
> http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring 
> -00.txt as a work item. The author will take it directly to IESG as an  
> individual draft.
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Shan Lu" <[email-masked]>
Date: Fri, 12 Nov 2004 15:49:26 -0500

I support the plan to move forward with the trunk group draft. In fact, my
company intends to implement it. 

However, I do believe there exists a technical hole in the draft, which I
raised on the list before. That is, since "tgrp" is defined as a tel-uri
parameter, it can not exist on its own without the actual tel-uri number. In
the case of originating trunk group (ie. PSTN-to-IP direction), the calling
number may be absent. The question is then how to express originating trunk
group.

Thanks,

Shan Lu  

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Jonathan Rosenberg
>Sent: Tuesday, November 09, 2004 4:03 PM
>To: list iptel
>Subject: [Iptel] getting group consensus on moving forward 
>with our workitems
>
>
>Folks,
>

* adopt 

* do not adopt 

Thanks,
Jonathan R.

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 15 Nov 2004 19:20:10 +0900

Hi,

I am not so happy to hear that cpc work will not move forward.
At least when interworking with ISUP or emulating the legacy PSTN,
cpc parameter seems to me to be useful.

For example, cpc=test paramter in P-Asserted-Identity header may
indicate that it is a test call so that it uses testing routing table
and is free of charge through the connection.
With cpc=priority, it can express it requires the call handling
with priority. (This should be done with R-P header, though)
With cpc=payphone, it may require to apply special charge rate, etc.

The scope of cpc work is probably limited to the legacy concept but
is useful in a certain situation.
Is it possible to move this forward to make an RFC as a working group
item, or as an individual submission?

Regards,
Takuya

> Cullen and the pending comments from Jonathan

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

---

From: David R Oran <[email-masked]>
Date: Mon, 15 Nov 2004 08:05:26 -0500

Is tel:;tgrp=foo not a valid tel: url?
If not, it ought to be.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 15 Nov 2004 08:30:57 -0600

Shan Lu wrote:

> I support the plan to move forward with the trunk group 
> draft. In fact, my company intends to implement it. 

Shan Lu:

Thanks.

> However, I do believe there exists a technical hole in the 
> draft, which I raised on the list before. That is, since 
> "tgrp" is defined as a tel-uri parameter, it can not exist on 
> its own without the actual tel-uri number. In the case of 
> originating trunk group (ie. PSTN-to-IP direction), the calling
> number may be absent. The question is then how to express 
> originating trunk group.

I am trying to understand the question better: Is it a
requirement in your network that the trunk group be
preserved even if the calling party number was absent?
Furthermore, how pervasive is this situation in general?

Clearly, if it is not, then we do the most minimal on
this (probably adding some text on what to do if the calling
party number is absent).  If it is a pervasive situation,
we can spend some capital trying to figure out a way to
combat this.

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

---

From: "Shan Lu" <[email-masked]>
Date: Mon, 15 Nov 2004 10:08:31 -0500

Dave,

Based on 2806bis-09, tel:;tgrp=foo is not valid. I am on the fence whether
it ought to be.

Thanks, Shan Lu

>From draft-ietf-iptel-rfc2806bis-09:

   telephone-uri        = "tel:" telephone-subscriber
   telephone-subscriber = global-number / local-number
   global-number        = global-number-digits *par
   local-number         = local-number-digits *par context *par
   <snip>
   global-number-digits = "+" 1*phonedigit
   local-number-digits  = 1*phonedigit-hex

>On Behalf Of David R Oran
>Sent: Monday, November 15, 2004 8:05 AM
>To: Shan Lu
>Cc: 'list iptel'
>Subject: Re: Comments on Trunk Group ID and RE: [Iptel] 
>getting groupconsensus on moving forward with our workitems
>
>
>originating  
>> trunk

---

From: "Shan Lu" <[email-masked]>
Date: Mon, 15 Nov 2004 10:45:59 -0500

Vijay,

Thanks for your response.

As you are aware, there are two scenarios where the originating number may
be absent. PSTN may withhold the number or the PSTN-SIP gateway may not
entrust downstrem endpoints with the number in case of calling party
privacy.

We have seen both cases and the need to know the incoming PSTN trunk group
when calling number is missing. In a lot applications, originating PSTN
trunk group info can be very useful for routing and revealing such info is
often not deemed to be a problem for privacy.

I am happy with the draft as far as destination TG is concerned. But I don't
think it should prescribe a formula for originating TG whose validity is
sometimes questionable.

Thanks, Shan Lu 

>On Behalf Of Vijay K. Gurbani
>Sent: Monday, November 15, 2004 9:31 AM
>To: Shan Lu
>Cc: 'list iptel'
>getting group consensuson moving forward with our workitems
>
>
>Shan Lu wrote:
>

---

From: "Shan Lu" <[email-masked]>
Date: Mon, 15 Nov 2004 10:52:20 -0500

Gone thru 2806bis-09 one more time, global-number-digits and
local-number-digits are defined as:

global-number-digits = "+" 1*phonedigit
local-number-digits  = 1*phonedigit-hex
<snip>
phonedigit           = DIGIT / [ visual-separator ]
phonedigit-hex       = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator     = "-" / "." / "(" / ")"

So would this be valid: "tel:-;tgrp=foo"?

Thanks, Shan Lu

>On Behalf Of Shan Lu
>Sent: Monday, November 15, 2004 10:09 AM
>To: 'list iptel'
>Subject: RE: Comments on Trunk Group ID and RE: [Iptel] 
>getting groupconsensuson moving forward with our workitems
>
>
>Dave,
>
>>> the case of originating trunk group (ie. PSTN-to-IP 
>direction), the  
>>> calling

---

From: Takuya Sawada <[email-masked]>
Date: Tue, 16 Nov 2004 11:51:26 +0900

Hi,

As per ABNF in 2806bis, local-number format MUST have phone-context
parameter. So, for example,

tel:-;phone-context=gateway.example.com;tgrp=foo

conforms to the rule in 2806bis.
You can reserve any number format for void-number, "-" or "####"
or whatever, under an administrative domain, e.g. "gateway.example.com".

I think this is an acceptable solution because tgrp draft says in 4.2;
"The use of the "phone-context" parameter in conjunction with this
draft is mandatory".
If we still want global void-number format for tel URI to indicate
tel-related properties without number, we need some more
work in 2806bis.
(This can be used with cpc parameter, if adopted.)

Regards,
Takuya Sawada

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: Takuya Sawada <[email-masked]>
Date: Tue, 16 Nov 2004 11:59:05 +0900

Hi,

In the examples in trunk-group I-D, tgrp parameter appears before
phone-context patrameter. This violates the rule of 2806bis, section 3;

   Each parameter name ("pname"), the ISDN subaddress, the 'extension'
   and the 'context' MUST NOT appear more than once.  The
   'isdn-subaddress' or 'extension' MUST appear first, if present,
   followed by the 'context' parameter, if present, followed by any
   other parameters in lexicographical order.

      This simplifies comparison when the "tel" URI is compared
      character-by-character, such as in SIP URIs [RFC3261].

So phone-context parameter MUST appear first, assuming that
2806bis will be approved as it is.

Regards,
Takuya Sawada

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 00:38:57 -0500

inline.

> cpc parameter seems to me to be useful.

SIP-T exists for cases like this. For this work to be justified, there 
needs to be a reason for it on an IP network.

> and is free of charge through the connection.

There is value in doing test calls and diagnostics. However, the problem 
is broader than just copying the ISUP cpc=test parameter, and it needs 
to be looked at more holistically.

> with priority. (This should be done with R-P header, though)

Priority call handling is also a more complicated subject. SIP already 
has a Priority header field for signifying priority to the called party, 
and work is underway in the conext of ieprep to prioritize calls during 
national emergencies.

> With cpc=payphone, it may require to apply special charge rate, etc.

We have RFC3840, which allows us to specify characteristics of the user 
agent. In any case, tying the presence of a capability/characteristic to 
a charging plan is a recipe for fraud.

> item, or as an individual submission?

To date, the reasons brought forward for this draft were all in the 
category of "because isup has this". Generally speaking, that has not 
been sufficient justification for undertaking new work. Rather, specific 
problems need to be brought forward and a case made that existing 
solutions do not suffice.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 00:41:13 -0500

> often not deemed to be a problem for privacy.

Can you explain these use cases? Specifically, under what cases is the 
originating trunk group used for routing decisions on the SIP side of 
the gateway?

-Jonathan R.

---

From: David R Oran <[email-masked]>
Date: Tue, 16 Nov 2004 02:23:57 -0500

> originating trunk group used for routing decisions on the SIP side of 
Uh, trunk group routing? E.G. all calls coming in on trunk group 234156 
(which happens to be from MCI in Alaska) and going to Tazmania get 
routed to C&W out trunk group 598275 (because I have a deal with C&W on 
calls to Tazmania this week).

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 16 Nov 2004 08:31:33 -0600

> phone-context patrameter. This violates the rule of 2806bis, section 3;
[...]
> 2806bis will be approved as it is.

Noted.

Thanks,

- vijay

---

From: Takuya Sawada <[email-masked]>
Date: Tue, 16 Nov 2004 23:38:34 +0900

Jonathan,

I admit that you are saying right thing, but...

comments inline.

> needs to be a reason for it on an IP network.
For ISUP-SIP-ISUP interworking, I agree that SIP-T fits perfectly.
But there are many cases that SIP-T, ISUP encapslation, can not apply.
For SIP UA originating scenario, normally SIP UA can not build IAM
message in INVITE request.

> to be looked at more holistically.
ISUP network can live with cpc=test for a long time :-)
Yes, SIP can be more sophisticated.
But the purpose of cpc=test is not diagnostics.
It is not for checking what is wrong but just for making sure 
it is good before making the resources or configuration available
to the ordinary usage.

> and work is underway in the conext of ieprep to prioritize calls during 
Priority header can be applicable for that purpose. 
In table 3 of RFC 3261, "proxy" column of Priority header indicates
"ar", add and read. I would be happier if it were "adr".
Resource-Priority header will be a good candidate if approved.

> a charging plan is a recipe for fraud.
RFC 3840 define Contact header parameters. I assume cpc parameter
to use with P-Asserted-Identity header. In that case cpc value
is network asserted as it is in ISUP.
For that purpose, defining new P- header or new P-Asserted-Identity
header parameter may be appropriate, though...

> solutions do not suffice.
I can not disagree "because isup has this" is not sufficient.
However, emulating ISUP with SIP is actually very important application
of SIP, unfortunately.
cpc parameter is the easiest way to emulate cpc parameter in ISUP.
Probably the easiest way is not necessarily the best way.
Umm.. does anyone have any other opinion?

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: "Shan Lu" <[email-masked]>
Date: Tue, 16 Nov 2004 09:51:51 -0500

>Sent: Tuesday, November 16, 2004 2:24 AM
>To: 'list iptel'
>gettinggroup consensuson moving forward with our workitems
>
>
<snip>
>calls to Tazmania this week).

That's what I want to way.

Regards, Shan Lu

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 16 Nov 2004 09:13:09 -0600

[...]
> I am happy with the draft as far as destination TG is concerned. 
> But I don't think it should prescribe a formula for originating 
> TG whose validity is sometimes questionable.

I think you mean above that the validity of the calling party
number is questionable, not the trunk group's?

OK, so given the ensuing discussion on the appropriateness of
carrying a trunk group even if the calling party number is not
available, it would seem that there are three ways to move
forward.

I would like to reach consensus on one of them.  Let me list
them and provide some pros and cons.

(1) As suggested by Shan Lu, using a "tel:-;tgrp=foo" in
     the Contact URI.

(2) In the Contact, use a tel URI of the form:
     "tel:0000;tgrp=foo;phone-context=example.com"

(3) In the Contact, use a SIP URI of the form:
     "sip:anonymous;tgrp=foo;phone-context=[email-masked]"

For (1), I wonder if the intent of the author of rfc2806-bis
was indeed to sanction such use.  While the ABNF may allow
it implicitly, should we endorse such a usage?  I am sure
with enough ingenuity, production rules of many ABNFs can
yield pretty interesting outcomes.

Maybe the WG can decide if the use of tel URI in this form
is okay.

In (2), the "0000" in the Contact URI serves as a filler.
The proxy receiving a request from its upstream gateway
with such a filler will know that an calling party number
was not provided.

Note that this case is distinct from a "0000" in the
R-URI of a request arriving from the PSTN, which could
signify a valid number in the domain of the proxy handling
the request.

(3) uses a SIP URI in the Contact header, avoiding the
ambiguities associated with (1) and (2).

My preference would be (3).

Any feedback and discussion most welcome.

Thanks,

- vijay

---

From: "Shan Lu" <[email-masked]>
Date: Tue, 16 Nov 2004 12:10:21 -0500

Hi all,

I support progressing the CPC draft as WG item. Comments inline. 

Regards,

Shan Lu

>On Behalf Of Takuya Sawada
>Sent: Tuesday, November 16, 2004 9:39 AM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: Re: [Iptel] getting group consensus on moving forward 
>withourworkitems
>
>
>Jonathan,
>

One such case would be a feature server (SBC, for example) managing end
users (user agents). But SIP/ISUP interworking is performed by a completely
separated entitiy. This interworking GW is not aware of end user profiles.
It will be useful for the feature server to inform the gateway a calling
UA's CPC so that IAM can be correctly constructed. Obviously this still
falls under "because ISUP has it" category. But at least it provides an
interworking motivation.  

<snip>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 15:15:12 -0500

inline.

> falls under "because ISUP has it" category. But at least it provides an

My point was, in all such cases that I have heard, there were other ways 
to indicate the desired information in a manner appropriate for SIP, and 
then these could be converted to their appropriate ISUP versions at a 
gateway.

For example, we have a mechanism for defining the characteristics of a 
UA (rfc3840) which can be used to signal things like the fact that this 
is a prison phone. Seems like such a characteristic does not depend on 
the fact that the endpoint is represented with a tel URI, and might be 
useful for SIP to SIP calls. This means that defining a tel URI 
parameter to map 1-1 with ISUP equivalents is the wrong way to do this.

In SIP, we have not elected to simply redefine every ISUP parameter into 
SIP. Rather, we defined things appropriately for a SIP network, and then 
specified how they get converted at a gateway. Why should CPC be different?

-Jonathan R.

---

From: Takuya Sawada <[email-masked]>
Date: Wed, 17 Nov 2004 16:59:10 +0900

Hi,

I think only (3) conforms to both 2806bis and RFC 3261.
But (3) is not tel URI at all. It is just the convention of the
SIP URI's user part usage.

Comments inline.

> (1) As suggested by Shan Lu, using a "tel:-;tgrp=foo" in
ABNF in 2806bis-09 explicitly does not allow the form above.

   context              = ";phone-context=" descriptor

>      "tel:0000;tgrp=foo;phone-context=example.com"
Contact header MUST be a SIP or SIPS URI according to RFC 3261,
section 8.1.18.
TEL URI is not allowed to appear in Contact header in INVITE request.

>      "sip:anonymous;tgrp=foo;phone-context=[email-masked]"
This is legal but not related to tel URI...
Probably we can live with this.
But we may have another choice.

(4)
sip:0000;tgrp=foo;phone-context=[email-masked]"

I do not have any preference between (3) and (4).

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: "Shan Lu" <[email-masked]>
Date: Wed, 17 Nov 2004 10:02:27 -0500

Takuya and Vijay,

I believe there are two steps here. The first one is to come up with a valid
tel-uri format. The second step is to put it in a SIP header and most likely
convert it to SIP URI.

WRT step 1, we have two proposals:

A) tel:-;phone-context=local;tgrp=foo
B) tel:0000;phone-context=local;tgrp=foo

Takuya correctly pointed out that "phone-context" must be present in both
formats. 

Assuming Proposal A passes 2806bis validity test, I definitely favor it. My
concern w/ B is the potential confusion that "0000" (or any other digit
string) may create in a local numbering plan.

Regards,

Shan Lu

>Sent: Wednesday, November 17, 2004 2:59 AM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: Re: [Iptel] Originating trunk group without calling 
>number (Was[Re:Comments on Trunk Group ID])
>
>
>Hi,
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 18 Nov 2004 11:10:56 -0600

Shan Lu wrote:

> Takuya and Vijay,
> 
> I believe there are two steps here. The first one is to come up 
> with a valid tel-uri format. The second step is to put it in 
> a SIP header and most likely convert it to SIP URI.
> 
> Assuming Proposal A passes 2806bis validity test, I definitely 
> favor it. 

I don't think A is a valid tel URI as per the production
rules of rfc2806bis.  Please double-check, but I do not
think it is.

> My concern w/ B is the potential confusion that "0000" (or 
> any other digit string) may create in a local numbering plan.

Yes, I agree.  I had pointed that out in my original email
as a disadvantage.

So, that leaves the following two choices (one from my original
email and the second one from Takyua's follow-up):

1) sip:anonymous;tgrp=foo;phone-context=[email-masked]
2) sip:0000;tgrp=foo;phone-context=[email-masked]

(2) still suffers from the ambiguity problem...so, I still
prefer (1).

The ambiguity in (2) is manageable since it is the proxy that
will be sending this URI in subsequent requests to the
gateway.  The gateway can associate a sip:0000 to mean that
the incoming number was absent when the call was initially
setup.  Of course, this is brittle and assumes some handshaking
between the gateway and the proxy (what if they want to use
sip:9999 instead?).

That is why I favor (1).  However, I do not have religious
feelings about this, so I am happy with whatever the WG
decides.

Comments....?

Thanks,

- vijay

---

From: Takuya Sawada <[email-masked]>
Date: Fri, 19 Nov 2004 21:47:41 +0900

Hi,

In 2806bis-09

I think "tel:-;phone-context=local;tgrp=foo" is sytactically OK.
(I don't know why visual-separator is inside square blackets.)

Anyway, I think now we reach the consensus to use the following
format;

sip:local-number-digits;phone-context=domain;tgrp=foo@domain

First, I want to ask whether we should
a) leave this as the matter of the adminstrative domain indicated
   by phone-context, or
b) define global unique format for void-number.

If a) no further question is needed.
If b), then, I want to ask what the unique format should be;
b-1) fixed non-number format which is not compliant to "local-number-digits"
     to avoid conflict (like "anonymous"),
b-2) fixed visual-separator only format to be syntacticaly compliant to
     "local-number-digits" and to avoid conflict (like "-"),
b-3) fixed number format to "fully" compliant to the intended format of
     "local-number-digits", but taking the risk of conflict (like "0000"),
b-4) fixed non-DIGIT format to reduce the risk of conflict comparing
     b-3) (like "####"),
b-5) any visual-separator only string which can be interpreted that any
     valid digits is not included (like "-", ".", "----", and so on),
b-6) void.
     (like sip:;phone-context=domain;tgrp=foo@domain)

b-6) is not compliant to ABNF in 2806bis unless 2806bis is modified
to allow it as follows;

    local-number-digits  = *phonedigit-hex

I don't know if it is good idea to modify, though. (maybe ugly)

I do not have any strong preference. Just pick one of these.
Ummm.. a) or b-2)/b-5)?

Comments?

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)