Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 May 2010 06:34:44 -0600

I just like to add I agree with the points Dean and Paul are making here

On Mar 17, 2010, at 6:26 PM, Dean Willis wrote:

> 
> On Mar 17, 2010, at 9:51 AM, Paul Kyzivat wrote:
>>> 
>> 
>> For those that truly describe properties of a URI (if there are any of those), you may be right.
>> 
>> For those that describe properties of a call, if they were carried as part of the call rather than as properties of the URI, then it wouldn't matter if the URI is sip or tel.
>> 
>> But in reality, even the properties that describe the caller aren't properly properties of the caller's URI. For instance, in principle the same originating "number" might be used by one phone in a prison and another in a police station.
>> 
>> ISTM that piggybacking these on the TEL uri is simply a convenient "ploy", because both phone numbers and these properties are managed by the ITU.
> 
> 
> Let's run through them:
> 
> ordinary: the caller has been identified and has no special features. At least not on this call; they might have some on another call, or might re-INVITE midstream if they change their mind, so don't count in it. Property of "call", not "caller".
> 
> Test: This is a test call. If the same guy calls you in 5 minutes, it might not be a test. Property of "call", not "caller".
> 
> operator: This call was generated by an operator position. Ostensibly, the caller is an operator? Probably a property of the "caller". One could envision putting this info in RFC 4474.
> 
> payphone: The calling station is a payphone. Again, a property of the caller.
> 
> unknown: I don't know what this means. It's probably got nothing to do with the caller.
> 
> mobile-hplmn/vplmn: The call was generated by a mobile device (property of the calling device, anyhow) in it's home/visited plmn (property of this call; doesn't persist if you call it back).
> 
> Some of the ANI II digits are things that are properties of a caller. Some, like Code 25, are attributes of call and caller. Many seem to specify specifc route-handling FOR THIS CALL, like not stripping off a leading "63".
> 
> So I'm not sure this is a useful categorization.
> 
> I'm pretty sure I don't want a "Type 67" modifier attached to A SIP URI. I'm also sure that most of these parameters make no sense on a TEL URI when that URI is used as a Request-URI; they don't route a call. They kindof make sense in a From: URI (or an RFC 4474 Identity header field), but they lack reversibility: one couldn't store this From: in a phone book, then turn around and call it back 5 minutes later. Consequently, the called party MUST understand them, or bad things will happen. This calls for an option tag, which is messy.
> 
> But I'm at a loss for proposing a better mechanism. Perhaps we could follow the SIP-T method and define another extension header field carried in the request?
> 
> 
> --
> Dean
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

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

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Wed, 12 May 2010 16:02:22 -0400

________________________________________
On Mar 17, 2010, at 6:26 PM, Dean Willis wrote:

I believe that this is a good solution.  If we want to transparently carry a PSTN-specific indicator through a PSTN -> SIP -> PSTN gateway situation, and that indicator does not translate well into SIP signaling, we should have a more or less opaque way of carrying it SIP, to be read by the SIP -> PSTN gateway process.  SIP-T already does this, and IIRC, the Q.850 variant of the Reason header has been proposed for this.  So let us define a header (or header variant) for carrying the OLI parameter.

We should also consider if some of the OLI information should be translated into "real" SIP signaling because SIP systems may need to act on it.  But that mapping does not need to be one-to-one.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 May 2010 16:21:43 -0400

If this info were only to be tunneled, and ignored by sip systems, then 
I wouldn't care.

The problem is that the ISDN systems are being replaced by SIP systems. 
And as that happens, those SIP systems need to provide a way to do the 
same thing. When the definitions of what these things mean are off in 
some ITU document, and are defined in terms of things that make no sense 
to a sip implementation, then it becomes very difficult to do the right 
thing.

	Thanks,
	Paul