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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 29 Nov 2004 12:51:05 -0600

Continuing our leftover discussion on representing the
trunk group if the calling party was not present in an
incoming session setup request...a question for the IPTEL
co-chairs is embedded in the writeup below.

With the subsequent confirmation from rfc2806bis author
regarding the inappropriateness of the following tel
URI (despite it being syntactically correct):

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

I would like to revisit my earlier suggestion to use
the following URI when the calling party is not known:

    sip:anonymous;phone-context=example.com;tgrp=[email-masked]

If we go this route, Shan Lu raises good questions on the
choice of this URI.  But I believe that these questions have
answers that fit within the current usage of SIP.  Namely,

 > I am a little confused about this. The draft started by defining a
 > tel-uri extension "tgrp" and now we seemed to end up reserving a
 > section of userinfo space in sip uri. My other concern with reserving
 > sip uri userinfo space is that we may need SIP WG blessing, which
 > will further delay the draft, if we can get the nod at all.

I don't think that this is insurmountable.  Note that RFC3261
uses the display name "Anonymous" and a URI of
[email-masked] for privacy reasons.  While I agree
that the use of such display names and URI is not normative in
RFC3261, the inherent understanding is that this use of 'anonymous'
is okay (at least, that is my read of the specification).

So, I do not believe that we will need to seek the blessing of
the SIP WG to use the username 'anonymous'.  IPTEL co-chairs can
provide further guidance if my understanding is flawed on
this count.

 > Also, a format that stays completely within tel-uri can be used in
 > applications other than SIP.

I believe that using the anonymous SIP URI in this manner is a way
to plug a corner case that you have identified; namely that the
calling party's number may be absent in the ISUP request coming into
a gateway.  This is an exception; the normal case will be to
populate the Contact with the SIP equivalent of the tel URI of
the calling party.

 > While I agree that the above sip uri format solves our
 > issue at hand, questions came to mind. For example, when calling
 > number IS present, do we use "tgrp" as part of tel-uri or do we use
 > sip uri similar to above?

When the calling number is present, the Contact is populated with
the SIP equivalent of the tel URI of the calling party.  The
username of anonymous MUST not be used in such cases.  We will make
this a normative behavior in the I-D.

Questions?  Comments?

Thanks,

- vijay

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Nov 2004 15:20:12 -0500

> URI (despite it being syntactically correct):

Actually, this is no longer syntactically correct. The BNF has been 
fixed in 48h to agree with the intent. No other URI scheme allows empty 
URIs, as far as I know.

---

From: "Shan Lu" <[email-masked]>
Date: Tue, 30 Nov 2004 12:12:00 -0500

>-----Original Message-----
>From: Henning Schulzrinne [mailto:[email-masked]] 
>Sent: Monday, November 29, 2004 3:20 PM
>To: Vijay K. Gurbani
>Cc: Shan Lu; 'Takuya Sawada'; IETF IPTEL WG
>Subject: Re: [Iptel] Originating trunk group without calling 
>number(Was[Re:Comments on Trunk Group ID])
>
>Vijay K. Gurbani wrote:

Fixing the BNF does not make the issue disappear. The issue is, tel uri, as
currently defined, does not allow expression of unavailable phone digits. 

For example, "tel:xxx;phone-context=internal" can mean something even when
"xxx" isn't there. Think of a calling number that is "internal" but has
requested privacy. 

I am not for or against any particular way to indicate empty phone number
(which may or may not lead to empty uri). But I think -A- way will be
desirable.

Regards,

Shan Lu