RE: [Iptel] Originating trunk group without calling number (Was[Re:Comments on Trunk Group ID])

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

>-----Original Message-----
>From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] 
>On Behalf Of Takuya Sawada
>Sent: Wednesday, November 17, 2004 2:59 AM
>To: vkg@lucent.com; shanlu@sentito.com
>Cc: iptel@ietf.org
>Subject: Re: [Iptel] Originating trunk group without calling 
>number (Was[Re:Comments on Trunk Group ID])
>
>
>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.
>
>> Shan Lu wrote:
>> 
>> > Vijay,
>> [...]
>> > 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.
>> 
>ABNF in 2806bis-09 explicitly does not allow the form above.
>
>   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
>   context              = ";phone-context=" descriptor
>   global-number-digits = "+" 1*phonedigit
>
>> (2) In the Contact, use a tel URI of the form:
>>      "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.
>
>> (3) In the Contact, use a SIP URI of the form:
>>      "sip:anonymous;tgrp=foo;phone-context=example.com@example.com"
>> 
>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=example.com@example.com"
>
>I do not have any preference between (3) and (4).
>
>Regards,
>Takuya
>
>> 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
>> -- 
>> 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
>> Iptel@ietf.org
>> https://www1.ietf.org/mailman/listinfo/iptel
>
>
>--------
>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
>tu-sawada@kddi.com
>
>_______________________________________________
>Iptel mailing list
>Iptel@ietf.org
>https://www1.ietf.org/mailman/listinfo/iptel
>

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www1.ietf.org/mailman/listinfo/iptel