Subject: [Sipping-tispan] Requirements 02e

From: Miguel Garcia <[email-masked]>
Date: Fri, 09 Sep 2005 15:56:48 +0300

Hi:

I have another working copy of the TISPAN requirements, now version 02e:

http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02e.html
http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02e.txt

And a diff version with respect 02d:
http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02d-to-e.html

The main changes this time are:

- Rewording of the CCBS/CCNR requirements as per our discussion. I have 
added a few definitions and try to reorder them sequentially, so that 
they are a bit easier to understand.
- Clarification that the TIP requirements are for an additional (to the 
asserted) identity.
- Addition of the Communication Waiting requirements

Please feel free to comment, but bear in mind that due to the TISPAN 
meeting next week most of the TISPANers will have limited time to discuss.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

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

---

From: Rocky Wang <[email-masked]>
Date: Mon, 19 Sep 2005 11:36:52 +0800

Hi, Migues,
As I considered, the requirement of overrding ACR service must be there
as a formal requirement. Maybe there are some ways that the called AS to
get enough information to determine that it can or cannot override the
ACR, but there are some cases the simulation service must be overrided,
including the case you listed in the 02a version. It can be like this:
1. The originating network shall be able to take enough calling party's
information to the terminating network to help to override the callee's
ACR service.
2. The terminating network shall be able to override the callee's ACR
simulation service if the caller is authorized to do this based on the
caller's information.

Rocky Wang

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Miguel Garcia
Sent: 2005?9?9? 20:57
To: [email-masked]'
Subject: [Sipping-tispan] Requirements 02e

Hi:

http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-r
equirements-02e.html
http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-r
equirements-02e.txt

And a diff version with respect 02d:
http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-r
equirements-02d-to-e.html

Please feel free to comment, but bear in mind that due to the TISPAN 
meeting next week most of the TISPANers will have limited time to
discuss.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 20 Sep 2005 09:45:53 +0300

Hi Rocky:

Yes, I think we agreed that this is a missing requirement, but we want 
to write it down when we have finished the other requirements, because 
it may happen that the calling part categories requirements help us in 
creating a proper dependency.

So this is not forgotten, it will be added at a later time.

BR,

      Miguel

---

From: Rocky Wang <[email-masked]>
Date: Tue, 20 Sep 2005 16:27:23 +0800

Hi, Migues,
   Thanks for you reply and I agree with you that maybe the new
requirements requires some more information of the call and the calling
party, e.g. the calling party categories. It can be completed now or
later.

   But I have some more doubts on TIP:
   REQ-TIP-1: In addition to any network asserted identity, it must be
              possible for the callee to indicate in a SIP response an
              additional identity where he is reachable for future
              direct communications.
   Does it mean the back identifier must be something like gruu? The one
who answers the call from one endpoint does not always mean the caller
should make a call to this endpoint directly later.

   REQ-TIP-3: The identity mentioned in REQ-TIP-1 is considered an end
              user supplied information that is not asserted by the
              network.
   Does it mean the network equipments just transfer the called party's
identifier provided by the called party endpoint? It must be also
asserted, I think. Or, it will cause some security problem.

Regards,
Rocky Wang

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: 2005?9?20? 14:46
To: Rocky Wang
Cc: [email-masked]
Subject: Re: [Sipping-tispan] Requirements 02e

Hi Rocky:

BR,

      Miguel

Rocky Wang wrote:

> Hi, Migues,
> As I considered, the requirement of overrding ACR service must be 
> there as a formal requirement. Maybe there are some ways that the 
> called AS to get enough information to determine that it can or cannot

> override the ACR, but there are some cases the simulation service must

> be overrided, including the case you listed in the 02a version. It can

> be like this: 1. The originating network shall be able to take enough 
> calling party's information to the terminating network to help to 
> override the callee's ACR service. 2. The terminating network shall be

> able to override the callee's ACR simulation service if the caller is 
> authorized to do this based on the caller's information.
> 
> Rocky Wang
> 
> 
>

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 21 Sep 2005 09:37:02 +0300

Hi Rocky:

inline discussion.

> should make a call to this endpoint directly later.

As far as I understand, there is not a requirement for this to be a 
GRUU. This is just another URI that would lead to the same person, but 
not necessarily to the same terminal.

> asserted, I think. Or, it will cause some security problem.

It means that the network does not verify the validity of this URI. It 
is up to the user to put something meaningful there. This is the 
requirement.

BR,

        Miguel

>>- Clarification that the TIP requirements are for an additional (to
> 
> the 
> 
>>asserted) identity.

---

From: Rocky Wang <[email-masked]>
Date: Wed, 21 Sep 2005 15:29:27 +0800

Hi, Miguel,

   For REQ-TIP-1, I agree with you and it is the same of ours. But
previously I misunderstand it that the direct communication means it
should reach to the same terminal.

   But for REQ-TIP-3, maybe there are still some security problem.
Suppose user B set and his terminal returns a subscriber C's URI back to
the calling party A, then what will happen? It will be possible that the
user A will be misleaded to make a call to C but he wants to make one to
user B actually.

Best Regards,
Rocky Wang

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: 2005?9?21? 14:37
To: Rocky Wang
Cc: [email-masked]
Subject: Re: [Sipping-tispan] Requirements 02e

Hi Rocky:

inline discussion.

Rocky Wang wrote:

>    Does it mean the back identifier must be something like gruu? The 
> one who answers the call from one endpoint does not always mean the 
> caller should make a call to this endpoint directly later.

>    Does it mean the network equipments just transfer the called 
> party's identifier provided by the called party endpoint? It must be 
> also asserted, I think. Or, it will cause some security problem.

BR,

        Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 21 Sep 2005 10:52:53 +0300

Inline discussion

> should reach to the same terminal.

Ok, I can add a clarification that there is not a requirement to end up 
in the same terminal.

> user A will be misleaded to make a call to C but he wants to make one to

Shame. As I said, there isn't a requirement for the network to assert 
the additional identity. This has been clarified a few times in the 
past, and remember, I am not the owner of the requirements, just the 
scribe. So from TISPAN point of view, the requirement is as is, and the 
security implications are accepted.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Sep 2005 09:39:35 -0400

Re TIP: What is the caller supposed to do with this multiplicity of 
addresses? Are we to imagine that the device will present the caller 
with all of them so that he may pick which to use when making a future call?

	Paul

Miguel Garcia wrote:
>> From: Miguel Garcia [mailto:[email-masked]] Sent: 
>> 2005?9?21? 14:37
>> To: Rocky Wang
>>>> added a few definitions and try to reorder them sequentially, so 
>>>> that they are a bit easier to understand.

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 22 Sep 2005 09:10:21 +0300

That is my understanding. If I recall correctly, the idea is to emulate 
the PBX, where the callee can indicate a direct-to-call number (URI).

/Miguel

Paul Kyzivat wrote:

>> Ok, I can add a clarification that there is not a requirement to end 
>> up in the same terminal.
>>
>>>
>> scribe. So from TISPAN point of view, the requirement is as is, and 
>> the security implications are accepted.
>>
>> /Miguel
>>
>>>
>>> Best Regards,
>>> Rocky Wang
>>>
>>> GRUU. This is just another URI that would lead to the same person, 
>>> but not necessarily to the same terminal.
>>>
>>>
>>> It means that the network does not verify the validity of this URI. 
>>> It is up to the user to put something meaningful there. This is the 
>>> requirement.
>>>
>>> BR,
>>>
>>>         Miguel
>>>
>>>
>>>> Regards,
>>>> Rocky Wang
>>>>  
>>>>> Please feel free to comment, but bear in mind that due to the 
>>>>> TISPAN meeting next week most of the TISPANers will have limited 
>>>>> time to discuss.
>>>>>
>>>>> /Miguel
>>>>>
>>>>
>>>>
>>>
>>

---

From: zhouqing <[email-masked]>
Date: Thu, 22 Sep 2005 17:04:53 +0800

Hi, all,

It's is mentioned in the draft of the sipping-tispan requirements:
   The Advice of Charge service allows the caller to request the
   displaying of tariff information related to the communication.  The
   caller can request the displaying of charging information at setup
   time (AoC-S), during a session (AoC-D), or at the end of it (AoC-E),
   including a few seconds after the communication has ended.

I have a doubt on the last sentence, "including a few seconds after the 
communication has ended", it is not present in WI01002 and WI03030, 
can someone tell me where this requirement come from?
Thank you!

ZhouQing(Justin)

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 22 Sep 2005 14:28:32 +0300

Justin:

You can find the requirement in the TISPAN document 03030, Section 
4.2.1. The reference to ETS 300 180 is added there as well.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Sep 2005 15:09:23 -0400

> the PBX, where the callee can indicate a direct-to-call number (URI).

OK, so the callee can indicate it. What happens at the calling end? Is 
it displayed instead of the callerid? Is it displayed in addition to the 
callerid? Is it retained by the calling UA and used in some circumstance?

This sounds a lot like the SIP Reply-To header, which can be there and 
carry information, but which has never had any clear utility, and so has 
essentially never been used.

	Paul

>>>>> party's identifier provided by the called party endpoint? It must 
>>>>> be also asserted, I think. Or, it will cause some security problem.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan 
>>>>>>
>>>>>> -r
>>>>>> equirements-02e.html
>>>>>>
>>>>>
>>>>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan 
>>>>>>
>>>>>> -r

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 23 Sep 2005 13:10:14 +0300

Paul Kyzivat wrote:

> 
> 
> Miguel Garcia wrote:
> 
>> That is my understanding. If I recall correctly, the idea is to 
>> emulate the PBX, where the callee can indicate a direct-to-call number 
>> (URI).
> 
> 

Actually, when we have been discussion solutions, the Reply-To header 
came one possibility to look at.

You say that the Reply-To header has no clear utility, and perhaps, this 
is an application where it could have a clear utility. I would expect 
this information to be offered by the UI, perhaps when saving the contact.

>     Paul

/MIguel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Sep 2005 10:56:23 -0400

Miguel Garcia wrote:
>>> emulate the PBX, where the callee can indicate a direct-to-call 
>>> number (URI).
>>
>>
>>
>> it displayed instead of the callerid? Is it displayed in addition to 
>> the callerid? Is it retained by the calling UA and used in some 
>> circumstance?
>>
>> carry information, but which has never had any clear utility, and so 
>> has essentially never been used.
> 
> 
> 

That would perhaps be helpful in supporting some *new* services. How 
would it help in a simulation service? Apparently it is simulating some 
existing service that has such an address. What is that service? How is 
this additional information used? Is it additional callerid info?

	Paul