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

["Jesske, R" <[e-mail]>]

Dear all,
Regarding the COLP/COLR and TIP/TIR we need two Terminating identifications.

1. A network provided user ID  = P-Asserted-Identity. This is already used in 3GPP for the interwoking of the COLP/COLR services. The P-Asserted-Identity identifies the sender of a SIP Message either in forward or in backward direction.

2. a user provided ID = ???. This was the requirement we have defined within TISPAN. So this ID should be send from the user directly it is like a "from header" in backward direction.

With regard to the interworking the P-Asserted-Identity in a 200OK response will be interworked to a Connected Number in a Answer Message.

The identity we need has to be interworked to the "Additional Connected number" within the "Generic number parameter".

I hope this helps.

Best Regards

Roland



> -----Ursprüngliche Nachricht-----
> Von: [e-mail] 
> [mailto:[e-mail]] Im Auftrag von Miguel Garcia
> Gesendet: Donnerstag, 8. September 2005 08:35
> An: Michael Hammer (mhammer)
> Cc: [e-mail]; Alexeitsev, Denis
> Betreff: Re: [Sipping-tispan] Re: TIP/TIR requirements
> 
> 
> Certainly this requires a bit of clarification. Thanks for 
> pointing this 
> out. We need to investigate what is this exactly.
> 
> /Miguel
> 
> Michael Hammer (mhammer) wrote:
> 
> > 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
> > 
> > 
> 
> -- 
> 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
> 

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