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

[Miguel Garcia <[e-mail]>]

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