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

[Miguel Garcia <[e-mail]>]

Roland:

Thanks for the clarification. Re-reading again the TIP/TIR requirements, 
  I think the confusion came because we didn't specify that the three 
listed requirements are "in addition to a network asserted identity". 
This clarification will help the reader understand that we are not 
speaking about a P-Asserted-Identity or Contact header, but about some 
user-indicated non-network-asserted identity. I will clarify this in the 
next version of the draft.

/Miguel

Jesske, R wrote:

> 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
> 
> 

-- 
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