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
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
