Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 Jun 2010 12:56:24 -0600

Can we identify the complete list of  semantic information this WG would cover? Some working groups have tried to charter with just "some information" and it is so vague that it really slows down the WG. 

Then can we look at at least one real world use case for each type of information - Take the pay phone case for example, what is the use case where someone needs to know the other end is a pay phone and what do they do differently.

On May 28, 2010, at 7:13 AM, Patel, Milan wrote:

> Hello,
>  
> Attached is a charter proposal for a WG to be formed for work pertaining to extensions to the tel URI – specifically, parameters for carrying the DAI, CPC, OLI and RN required for primarily interworking scenarios to ISUP/PSTN.
> Feedback is appreciated.
> Regards,
> Milan
>  
>  
> From: Patel, Milan 
> Sent: Tuesday, May 25, 2010 11:16 AM
> To: Cullen Jennings; [email-masked]'; Robert Sparks; 'Gonzalo Camarillo'
> Cc: [email-masked]; 'Sumanth Channabasappa'
> Subject: Charter proposal
>  
> Hi all,
>  
> Attached is a charter proposal for a WG to be formed to handle Internet Drafts pertaining to the Tel URI. Specifically these are the DAI draft and the CPC/OLI draft and some further work on the RN parameter.
> Feedback is welcome.
>  
> Kind regards,
> Milan
> <XXXX WG charter proposal.txt>

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 3 Jun 2010 10:26:42 -0600

I did a bit more thinking about how to make progress on this charter and have a few ideas how to get the conversation going. The currently charter is pretty unconstrained and does not explain what the problem is the WG will solve.  It roughly paraphrases to there are some bits in some other telephone protocols that are not yet in SIP therefore we need to put them in the tel URI. The IPTEL WG had pretty clear consigns that was not an appropriate way to approach the problem and I would be surprised to see that consensus has radically changed. I do think people would be very favorable in putting in extensions that made sense to do this way. My suggestion is to figure out what is the problems we are actually trying to solve, then find a way to solve theses problems. I do think there are problems to be solved that we do need some extensions - it's just not clear where or how to do them. To help poke at what the problem is, let me ask some questions that might get the conversation going. 

So the information being transported is roughly A tel URI to indicate how the CIC code was selected. Why does the receiver need this information and what are the use case for it? If we can be clear about that, I think ti will help define what information needs to be moved and then we can figure out the appropriate place to put it in the protocol. 

In the prison use case, the use case seems to be "Allow a user to block phone call that come from a prison". Is that about it or is there more?

I don't understand the payphone use case. Is it "charge more the call if it came from a payphone?"

Can you list out all the information that is needed from the OLI/CPC and they we can try and sort out the use cases for what parts a SIP device needs to understand and what parts only need to be transported across the SIP network. 

Cullen

Cullen Jennings

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Thu, 3 Jun 2010 21:25:12 -0400

________________________________________
From: Richard Shockey [[email-masked]]

Though the larger issue of how to carry these types of messages or metadata
(CNAM,CIC,SPID) in SIP has not been fully addressed either.

Needless to say we have had a vigorous discussion over this ongoing issue in
both DRINKS and the E2MD BOF ( NGN ENUM ) list.
________________________________________

I suspect that any truly useful solution will be similar to what is being solidified regarding translation Q.850 "response codes" into SIP so that SIP can be used as a transit network between two SS7 networks:  (1) As much as possible, the *meaning* of the Q.850 code is translated into a SIP response code, and (2) the original Q.850 code is carried directly in a way for which SIP is transparent, in order to be resurrected at a SIP-to-SS7 gateway.

In the case of CIC and friends, carrying the codes directly in a suitable header is quite appropriate.  But I think that the approach of attaching them directly to the originating or destination URI is not architecturally sound.

Dale

---

From: "Patel, Milan" <[email-masked]>
Date: Fri, 4 Jun 2010 06:40:55 -0400

Hi Cullen,

One thing needs to be made clear and that is the called party isn't
required to handle the information. Especially in SIP, the CPC for
example would be subject to trust domain rules. The information is
required for SIP intermediaries, or in the case of interworking to the
PSTN, the information is required for processing within the PSTN and not
by the endpoint device or user. 

Dale, the solutions currently proposed for the CPC/OLI/DAI is something
that I believe is already deployed, and in your opinion, might not be
the most architecturally sound solution, but we would need to factor
into account current deployments. 

Best regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of WORLEY, Dale R (Dale)
Sent: Friday, June 04, 2010 2:25 AM
To: Richard Shockey; 'Paul Kyzivat'; Patel, Milan
Cc: [email-masked]
Subject: Re: [dispatch] Charter proposal for drafts related to the tel
URI

Though the larger issue of how to carry these types of messages or
metadata
(CNAM,CIC,SPID) in SIP has not been fully addressed either.

Needless to say we have had a vigorous discussion over this ongoing
issue in
both DRINKS and the E2MD BOF ( NGN ENUM ) list.
________________________________________

I suspect that any truly useful solution will be similar to what is
being solidified regarding translation Q.850 "response codes" into SIP
so that SIP can be used as a transit network between two SS7 networks:
(1) As much as possible, the *meaning* of the Q.850 code is translated
into a SIP response code, and (2) the original Q.850 code is carried
directly in a way for which SIP is transparent, in order to be
resurrected at a SIP-to-SS7 gateway.

In the case of CIC and friends, carrying the codes directly in a
suitable header is quite appropriate.  But I think that the approach of
attaching them directly to the originating or destination URI is not
architecturally sound.

Dale
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Fri, 4 Jun 2010 08:41:18 -0400

________________________________________
From: Patel, Milan [[email-masked]]

Beware that those who come to the IETF to get blessed things that they have already deployed are often disappointed.  You cannot compel the IETF to approve things.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Jun 2010 09:36:48 -0400

> into account current deployments. 

We can certainly take that into account. But we don't rubber stamp 
everything that comes along that has been deployed. Architectural 
soundness is a very important consideration.

	Thanks,
	Paul