RE: [Sipping-tispan] Re: TIP/TIR requirements

["Michael Hammer \(mhammer\)" <[e-mail]>]

Miguel,

The second paragraph below says that the terminating exchange verifies
the information received from the connected user before passing on to
the originating exchange.

>From Q.731.5:

"Connected line identification presentation (COLP) is a user facility
that enables a user to be informed, on outgoing calls, of the address of
the connected party. When provided the facility applies to all outgoing
calls except for when the connected party has the connected line
identity restriction (COLR) facility active.

The connected number may be provided by the destination local exchange
or by the access signalling system of the connected user. If the
connected party number is received from the connected user, the
information is normally verified and passed to the originating exchange.
If no information is received from the connected user, the destination
exchange shall generate the connected number.

By special arrangement, verification of the connected party number
information provided by the user may be inhibited.  The information is
conveyed by the network in the generic number parameter field of the
answer (ANM) or connect (CON) message. The service has no impact on the
signalling procedures.

The connected line identity (COL) is the ISDN number of the connected
party (with additional address information, e.g. connected party
sub-address, if any) which may be provided by the network or by the
connected party or partially by the network with the rest provided by
the connected party.

Only full international number, i.e. including the country code, should
be passed across the international boundary.

Moreover, the information on the COL may include address information
generated by the connected user and
transparently transported by the network. The sub-address is subject to
a maximum of 20 octets. The network is not responsible for the content
of this additional address information."

That last paragraph suggests some sub-address information may be passed
transparently by the network.  Draw your own conclusions.

Mike


> -----Original Message-----
> From: Miguel Garcia [mailto:[e-mail]] 
> Sent: Wednesday, September 07, 2005 2:21 PM
> To: Michael Hammer (mhammer)
> Cc: Schmidt, Christian; [e-mail]; Alexeitsev, D
> Subject: Re: [Sipping-tispan] Re: TIP/TIR requirements
> 
> I am certainly not the expert in supplementary services in 
> the PSTN, but
>   I have been told that this identity is never asserted by 
> the network, so the callee can put there whatever he wants.
> 
> During the discussions of solutions we looked at headers like 
> Reply-To, and In-Reply-To, but their semantics are well 
> defined and do not match the requirements.
> 
> /Miguel
> 
> Michael Hammer (mhammer) wrote:
> 
> > If this is not an asserted identity, then what good is it?
> > 
> > I thought that the CLIP and COLP were complementary and 
> identical in 
> > type.  But, perhaps that is a subtlety I missed.
> > 
> > Mike
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: [e-mail] 
> >>[mailto:[e-mail]] On Behalf Of Miguel Garcia
> >>Sent: Wednesday, September 07, 2005 4:03 AM
> >>To: Schmidt, Christian
> >>Cc: [e-mail]; Alexeitsev, D
> >>Subject: [Sipping-tispan] Re: TIP/TIR requirements
> >>
> >>Inline discussion.
> >>
> >>Schmidt, Christian wrote:
> >>
> >>
> >>>Some comments / questions concerning the TIP/TIR requirements:
> >>>
> >>>- What happens, when the caller is in PSTN and the callee
> >>
> >>provides a
> >>
> >>>SIP URI as identity? Will it be translated at the gateway
> >>
> >>to a E.164 number?
> >>
> >>I don't know what people want to do in this scenario, but in my 
> >>opinion the responsibility lies in the calee, so if the 
> callee offers 
> >>only a SIP URI, and not both a SIP URI and TEL URL, then 
> the network 
> >>shouldn't be doing this type of translations. Remember that this is 
> >>not an asserted identity, so this should be end-to-end information
> >>
> >>
> >>>- TIP-1: type error: calle > callee
> >>
> >>Fixed.
> >>
> >>
> >>>- How to handle identity restriction from PSTN/ISDN side? 
> Sould the 
> >>>gateway delete both identity information and restriction 
> >>
> >>information 
> >>
> >>>in this case?
> >>
> >>If we build on the trust model, and if we consider that the 
> >>PSTN Gateway trusts the IMS network, then I would say no, 
> >>delete at the trusted/not-trusted boundary.
> >>
> >>
> >>
> >>>EQ-TIP-4: If identity information and restriction indication is 
> >>>included in a message, the gateway may not transfer the 
> >>
> >>identity information.
> >>
> >>Is this a proposal for a new requirement? What is the actual 
> >>requirement here? This looks like a clarification.
> >>
> >>/Miguel
> >>
> >>>
> >>>Regards,
> >>>Christian
> >>>
> >>
> >>-- 
> >>Miguel A. Garcia           tel:[phone]
> >>sip:[e-mail]
> >>Nokia Research Center      Helsinki, Finland
> >>
> >>
> >>_______________________________________________
> >>Sipping-tispan mailing list
> >>[e-mail]
> >>https://www1.ietf.org/mailman/listinfo/sipping-tispan
> > 
> > 
> 
> -- 
> Miguel A. Garcia           tel:[phone]
> sip:[e-mail]
> Nokia Research Center      Helsinki, Finland
> 

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan