Subject: [Sipping] PoC-settings event package

From: Miguel Garcia <[email-masked]>
Date: Thu, 16 Jun 2005 13:16:18 +0300

Hi:

I have just submitted a new version of the poc-settings event package 
draft. Until it is available, you can download a copy from:

http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.txt
or
http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.html

This contains the mostly editorial comments that I got in the mailing 
list and in the exper review.

Regards,

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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jun 2005 09:57:41 -0400

I have one question on this document:

    5.16  Multiple Sources for Event State

    RFC 3903 [8] requires event packages to specify whether multiple
    sources can contribute to the event state view at the ESC.

    This event package allows different EPAs to publish the PoC settings
    for a particular user.  For a given user the ESC will consider the
    last received PoC settings documents segment as the valid updated
    event state.

I don't follow this. If two phones are registered and publishing then 
you take the most recent publication as applying to the AoR as a whole?

That doesn't make sense to me. One might be in auto answer mode and the 
other in manual mode. When a call comes in, the proper treatment is a 
function of which the call is directed to.

There is a problem in that there is no good way for the ESC to correlate 
the published settings with a particular registration, but that seems to 
be what is needed.

As described, the two phones will both be registered and will both 
periodically update their POC settings in an uncoordinated way. Just 
doesn't work.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 27 Jun 2005 10:57:55 +0300

Hi Paul:

I acknowledge the problem, which hasn't been a problem for the OMA folks 
since they assume a single terminal for a given identity. Of course, 
this does not solve anything, and I agree this issue should be fixed.

I am thinking of possible solutions to this problem. Linking the 
poc-settings to the device-id or contact address does not seem to solve 
anything, because the PoC server does not have any registration information.

So I will start some discussion with the OMA folks as for what is an 
acceptable solution for this... Perhaps we should have been using hard 
state publication instead... sigh.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Jun 2005 10:10:32 -0400

> state publication instead... sigh.

Why isn't this another attribute of presence state? The POC client then 
needs to be a presence client and see individual tuples. It can then 
decide how to handle on a per-tuple basis.

	Paul

>> That doesn't make sense to me. One might be in auto answer mode and 
>> the other in manual mode. When a call comes in, the proper treatment 
>> is a function of which the call is directed to.
>>
>> There is a problem in that there is no good way for the ESC to 
>> correlate the published settings with a particular registration, but 
>> that seems to be what is needed.
>>

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 28 Jun 2005 10:54:47 +0300

Hi Paul:

Yes, this could have been combined with presence. Unfortunately the data 
model wasn't still that developped when OMA analyze presence as an 
option. In fact, presence is an optional function in PoC. So a bit of 
historical reasons.

/Miguel

Paul Kyzivat wrote:

> 
> 
> Miguel Garcia wrote:
> 
>> Hi Paul:
>>
>> I acknowledge the problem, which hasn't been a problem for the OMA 
>> folks since they assume a single terminal for a given identity. Of 
>> course, this does not solve anything, and I agree this issue should be 
>> fixed.
>>
>> poc-settings to the device-id or contact address does not seem to 
>> solve anything, because the PoC server does not have any registration 
>> information.
>>
>>>> I have just submitted a new version of the poc-settings event 
>>>> package draft. Until it is available, you can download a copy from:
>>>>
>>>> This contains the mostly editorial comments that I got in the 
>>>> mailing list and in the exper review.
>>>>
>>>> Regards,
>>>>
>>>>         Miguel
>>>
>>>
>>>
>>>