Subject: RE: [Sip] What is the mapping of ANI II digits to rpi-np?

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 3 Oct 2001 03:11:52 -0700

Flemming,

I think authentication and generation are unrelated to the argument - it is
a case of representation and scope. The RPI header (which includes both the
URL and RPI header parameters) can be signed/protected under the proposed
privacy framework. The appropriate RPI headers can be added and signed by
any entity that has the appropriate information along the call path (eg
logically in this case the originating SS7-SIP gateway).

What is the rpi-np parameter really trying to accomplish? If it is trying to
re-invent the ANI II wheel then rpi-np does not make sufficient sense (IMO).
The OLI refers to a telephone subscriber and therefore placing that
information with the telephone subscriber as Romel suggested is the right
way to go. 

If the rpi-np is trying to do solve some more generic "where is this entity
calling from" question, then we need to examine and describe more fully what
it is trying to accomplish and how it is to be used. [Otherwise we get a
scheme that is not helpful to those want to do SS7 entity identification
(without fully-blown SIP-T) and also may not be useful for those who do not
need to solve the above problem.]

Hence, if we use the oli tel: url parameter as Romel suggested (in addition
to any RPI parameters), then we largely free ourselves from the burden of
needing bidirectional mappings for SS7 when trying to come up with a useful
scheme for rpi-np.

Regards,

Robert.

P.S. Mike, I believe Romel is actually suggesting the use of numeric values
for the oli tel: url parameter.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2001 1:10 AM
> To: Romel Khan
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np?
> 
> 
> 
> 
> Romel Khan wrote:
> 
> > How about do something like:
> > From: <sip:13082536367;oli=[email-masked];user=phone>
> > where oli = originating line information = ani-ii
> >
> 
> Who adds the ANI II ? How do you know you can trust it ?
> 
> -- Flemming
> 
> 
> >
> > This encloses the II information within telephone URL 
> consistent with
> > RFC2806 and makes it independent of SIP.
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Saturday, September 29, 2001 8:05 PM
> > To: [email-masked]; [email-masked]
> > Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np?
> >
> > To all,
> >
> > In a message dated 9/28/01 5:11:08 PM Eastern Daylight Time,
> > [email-masked]
> > writes:
> >
> > << Hi guys,
> >
> >  I had initially sent out a question on this issue and received no
> >  responses; so I'm trying again... :^)
> >
> >  I'm trying to understand the appropriate translation of 
> ANI II digits to
> >  their SIP equivalent.  However, when
> >  I try to match the currently defined ANI II digits from
> >  http://www.nanpa.com/number_resource_info/ani_ii_assignments.html
> >  against the keywords defined in
> >  Appendix A of draft-ietf-sip-privacy-02.txt, it appears to 
> be a sparse,
> >  non-invertible mapping.
> >
> >  So, I have a few questions:
> >  1) Is there a more recent version of this syntax?
> >  2) Could someone define a less sparse, invertible mapping as a best
> >  current practice?
> >  3) Should we instead just define a new tag such as, 
> ";ani-ii=number" ?
> >  4) Other ideas? >>
> >
> > <<My comment:
> > It seems best to use your suggestion 3 - simply define a tag for
> > "ani-ii=number" and use the currently defined numbers, not 
> some newly
> > invented list of keywords that have unknown meanings. Let's 
> not reinvent the
> >
> > wheel!
> >
> > Mike Pierce
> >
> > _______________________________________________
> > Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> >
> > _______________________________________________
> > Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> 
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Alan Johnston <[email-masked]>
Date: Wed, 03 Oct 2001 11:19:09 -0500

Robert,

See my comments below.

Alan Johnston
sip:[email-masked]

"Fairlie-Cuninghame, Robert" wrote:

> What is the rpi-np parameter really trying to accomplish?

The main purpose of the rpi-np is to allow some of the identification
information about a PSTN endpoint originator that is available in the PSTN to be
available in SIP if the call routes PSTN to SIP.  For the PSTN to SIP to PSTN
case, only SIP-T will work.

The intent was to map only the information that might be useful to a SIP network
in routing a call.  For example, knowing that the call is coming from a payphone
could trigger some service logic in a proxy that could cause INVITE routing to
change.  However, coin deposit signaling information is not at all relevant to
routing the INVITE. (If one wants to build SIP payphones, there are far more
elegant ways than reusing coin signaling in the PSTN.)

> If it is trying to

This is not the intent.  Also, note that simply saying ii=53 does not work, as
53 may have different meaning depending on the flavor of ISUP being used.

> scheme for rpi-npi.

> for the oli tel: url parameter.

Numeric values do not make sense, as they have only local significance.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 03 Oct 2001 12:24:14 -0400

> logically in this case the originating SS7-SIP gateway).

Right - that was my point (as opposed to having it in the From header).

> re-invent the ANI II wheel then rpi-np does not make sufficient sense (IMO).

I'll defer to Alan Johnston on that.

> information with the telephone subscriber as Romel suggested is the right

For the POTS only case I agree its natural and very easy to do that. Since
tel-URL's can be passed in the Remote-Party-ID header, we just define a new
tel-url extension parameter and we are done (until the next ISUP parameter comes
along and before we know it we transport ISUP in a tel-URL). However, the
question is whether you want to do something more general ?

> need to solve the above problem.]

I agree.

> needing bidirectional mappings for SS7 when trying to come up with a useful

As long as we are only worried about the PSTN to SIP interworking case (really a
SIP-T issue then), then I agree with defining a tel-URL extension for this.

-- Flemming

--
Flemming Andreasen
Cisco Systems