[Rest] REMINDER: REST teleconf on Feb 6th
Shida Schubert
shida at ntt-at.com
Wed Feb 11 06:41:55 CST 2009
Hi Sanjay;
Thanks for the note, I apologize for my belated
action. As I noted on the e-mail I sent out, I have been
knocked out by the flu going around in Japan.
Below is the pointer to the e-mail by Markus.
http://www.ietf.org/mail-archive/web/bliss/current/msg00883.html
http://www.ietf.org/mail-archive/web/bliss/current/msg00884.html
Many Thanks
Shida
On 9-Feb-09, at 3:53 PM, Sanjay Sinha (sanjsinh) wrote:
> I am sending out some notes I took during the meeting.
>
> - While REST framework in SIP can be generic, we decided to
> concentrate
> on configuration around ACH implementation. Shida mentioned emails
> sent
> by Markus, some folks probably were not familiar with it, so pl.
> find it
> attached for reference.
>
> - It was decided to come up with use cases that could benefit from a
> REST based approach
>
> - We decided to meet week of Feb 16 - Feb 20 to go over use cases and
> decide next steps. Use cases can be sent/discussed on this list before
> that.
>
> Thanks
> Sanjay
>
>
>> -----Original Message-----
>> From: rest-bounces at bliss-ietf.org
>> [mailto:rest-bounces at bliss-ietf.org] On Behalf Of Shida Schubert
>> Sent: Thursday, February 05, 2009 3:20 PM
>> To: rest at bliss-ietf.org
>> Subject: [Rest] REMINDER: REST teleconf on Feb 6th
>>
>> All;
>>
>> As no one objected to the time change, I am sending the
>> reminder of the meeting tomorrow (Feb 6th) with the change reflected.
>>
>> Here is the rough agenda I can think of, please provide me
>> with any suggested correction.
>>
>> Proposed Agenda
>> ----------------------
>> 1. Introduction?
>> 2. Way forward
>> - Discussion on requirements/how to gather more requirements.
>> - Scoping the work.
>>>> Defining litmus test for deciding what should be in
>> scope and what's out of scope.
>>
>> 3. Set up rough milestones for IETF 74.
>> 4. Action Items/Task delegation etc.
>> 5. Scheduling next meeting.
>> ---------------------
>>
>> Bridge Information
>> ---------------------
>> Dial-In: +1 604-320-3344
>> then use the following extension to access the conference
>> system: 7500 then use the following code to enter the room: 7201
>>
>> Schedule
>> ---------------------
>> Feb 6th 15:00GMT-16:00GMT
>> ---------------------
>>
>> Regards
>> Shida
>>
>> _______________________________________________
>> Rest mailing list
>> Rest at bliss-ietf.org
>> http://bliss-ietf.org/mailman/listinfo/rest_bliss-ietf.org
>>
>
> From: <Markus.Isomaki at nokia.com>
> Date: January 20, 2009 4:26:56 AM JST
> To: <bliss at ietf.org>
> Subject: [BLISS] ACH configuration next steps?
>
>
> Hi,
>
> I'd like to start discussion on ACH configuration so that we can
> produce something by IETF 74. By ACH configuration I mean a
> mechanism to enable setting things such as to which number/URI the
> proxy should forward the incoming call when the user is busy.
>
> I've studied the case a bit and it appears to be that a good
> starting point would be to use SIMPLE HTTP (call it REST if you
> like) mechanism to create, read, write and delete a ruleset that
> looks awfully lot like CPL. In fact, I think we should just take CPL
> as a starting point and perhaps just cut some unnecessary features
> out of it. The main things to figure out would be just where to
> locate the resource(s). There could be more than one of them if we
> want to enable things like multiple profiles. I assume each profile
> would have its own ruleset. And hey, why not borrow the URI
> structure from XCAP AUID, that would save us from re-inventing that
> wheel. We could also borrow the extensibility model from XCAP, i.e.
> using XML namespaces and discovering which of them are supported by
> the server.
>
> I believe this would be an approach where we could complete
> something in a reasonable time. Is there any reason why that
> approach would not work?
>
> I've also looked at other approaches, such as using REST by breaking
> the dataset into a bunch of resources. One resource could be for
> instance the target for call forwarding on busy. That approach would
> work easily for the basic use cases too, but I believe it has two
> major shortcomings:
> * It is hard to build rules that have multiple conditions (e.g.
> take UA response ("busy")and time-of-day into account. That requires
> some kind of a rule language, such as CPL, where you can combine and
> order conditions and actions.
> * The extensibility model is undefined.
>
> Markus
> _______________________________________________
> BLISS mailing list
> BLISS at ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
>
>
>
> From: <Markus.Isomaki at nokia.com>
> Date: January 20, 2009 4:55:37 AM JST
> To: <bliss at ietf.org>
> Subject: [BLISS] ACH configuration requirements: replicating
> GSMfunctionality
>
>
> Hi,
>
> I've looked at ACH configuration requirements and would like to make
> sure one fundamental set of requirements is addressed.
>
> GSM is the most popular system for mobile telephony with about 3
> billion users. So, it is a pretty massive installed base. Eventually
> that service is expected to be REPLACED by SIP based mobile VoIP.
> One important missing piece still is how to replace the call
> handling settings supported by GSM. This is probably going to be a
> mandatory feature for many deployments, as even if using such
> settings is not that popular, there is at least some amount of users
> who use some of them so it'd be hard to just drop them in a
> commercial deployment.
>
> So, here's a list of settings that virtually every GSM phone offers,
> hidden somewhere in the depths of the menus:
>
> * Call forwarding unconditional: either to voicemail or to any other
> number.
> * Call forwarding on busy: either to voicemail or to any other number.
> * Call forwarding on no answer: either to voicemail or to any other
> number.
> * Call forwarding when not registered: either to voicemail or to any
> other number.
> * Call forwarding when not reachable: either to voicemail or to any
> other number.
>
> (There's very little difference between the last two cases from
> user's point of view so it would be fine to combine them.)
>
> The requirement is that there has to be a way to configure these
> settings on the SIP proxy/B2BUA implementing ACH for the user. At
> minimum this means 5 (or 4 if we combine) attributes with value
> "voicemail" or any sip/tel URI, and one attribute that defines the
> sip/tel URI for voicemail.
>
> Then there are settings for call barring too:
>
> * Barring on all outgoing calls: on/off
> * Barring on all outgoing international calls: on/off
> * Barring on all outgoing calls when roaming except to own service
> provider: on/off
> * Barring on all incoming calls: on/off
> * Barring on all incoming calls when roaming: on/off
>
> (The exact meaning of "roaming" in case of SIP is probably
> undefined, and does not matter if charging is depending where you
> are attached to the network. However, in some services there might
> be a difference.)
>
> So, this would mean at minimum that we need to define a way to set 5
> boolean attributes.
>
> I believe that whatever BLISS does for ACH configuration, these use
> cases must be solved in the very first baseline version of the
> solution.
>
> At minimum we could design an amazingly simple solution to just
> solve this case. But since this is the RAI area ;) and we do have
> other requirements (for instance the reqs draft talks about time-of-
> day or caller identity based rules), I'd suggest HTTP/REST + CPL as
> a starting point, as I wrote in another mail.
>
> If there is interest, I could write the GSM reqs in a proper brief
> Internet-Draft in a more verbose way with references to the
> corresponding GSM specs.
>
> And, as always, a note that 3GPP is too working in this problem
> space and it would be good to make some progress in BLISS to
> discourage them from developing their own specific solution.
>
> Regards,
> Markus
> _______________________________________________
> BLISS mailing list
> BLISS at ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://bliss-ietf.org/pipermail/rest_bliss-ietf.org/attachments/20090211/f352ce6b/attachment.html>
More information about the Rest
mailing list