Re: Query related to UDUB for voice calls.
HI Denis, Thanks for the response. I feel like due to the limitation of the AT modem interface through 27007, we are missing the basic functionality defined in the other specifications for UDUB. Please comment. Thanks, Sankar. On Sat, Oct 2, 2010 at 4:26 AM, Denis Kenzior denk...@gmail.com wrote: Hi Rajesh, Please, NO top posting on this list. On 10/01/2010 04:31 PM, rajesh.naga...@elektrobit.com wrote: Hi Sankar, My understanding is that when a call is rejected by the user, irrespective of whether its an incoming call or a waiting call, the cause value for the release call should be set to UDUB, so that for the remote subscriber the User Busy note will be shown in the UI if the voice mailbox is not configured. In the message based modem case, we set the cause value to UDUB with the release call request and in the AT based modem case we should send AT+CHLD=0, which will in turn set UDUB. So for the Incoming call hangup case if we call vc-driver-hangup(vc, generic_callback, vc); in AT case it will send AT+CHUP which i am not sure is inturn going to set the cause value to UDUB or not (Someone with AT based modem experience can confirm this ???), but for message based modem case its going to call the release call request with cause value Release by user, which will be translated to normal call clearing. So in ofono core the hangup case for Incoming call should be handled in same way as Waiting call by calling vc-driver-set_udub(vc, generic_callback, vc); instead of vc-driver-hangup(vc, generic_callback, vc);, so that UDUB cause is sent to the remote party Unfortunately AT modems do not allow any CHLD operations on incoming calls, including CHLD=0. CHLD=0 can only be used to set UDUB on waiting calls. To release incoming calls you must use ATH or +CHUP. Since AT command modems are the only ones described by 3GPP standards, that is the modem interface oFono assumes. If your modem deviates from this standard, then you need to make sure to send the proper release cause for incoming calls in the driver for your target hardware. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Query related to UDUB for voice calls.
Hi Sankar, This is your final reminder about not top-posting on this list. All further Emails like this will be ignored. On 10/04/2010 01:58 AM, Sankar wrote: HI Denis, Thanks for the response. I feel like due to the limitation of the AT modem interface through 27007, we are missing the basic functionality defined in the other specifications for UDUB. Please comment. What limitation? If I hang up an incoming call I expect it to go to voice mail. Why would you want to do it any other way? oFono has to work with both AT and non-AT command modems, without becoming overly complicated. This means that the core has to assume some behavior. Since the only viable standard is 27.007, that is what we stick to (even though some AT modem manufacturers don't) However, in this particular case the behavior is the one that makes the most sense to the user. So I'm really not seeing your concern here... Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Query related to UDUB for voice calls.
Hi Sankar,
My understanding is that when a call is rejected by the user,
irrespective of whether its an incoming call or a waiting call, the
cause value for the release call should be set to UDUB, so that for the
remote subscriber the User Busy note will be shown in the UI if the
voice mailbox is not configured. In the message based modem case, we set
the cause value to UDUB with the release call request and in the AT
based modem case we should send AT+CHLD=0, which will in turn set UDUB.
So for the Incoming call hangup case if we call vc-driver-hangup(vc,
generic_callback, vc); in AT case it will send AT+CHUP which i am not
sure is inturn going to set the cause value to UDUB or not (Someone with
AT based modem experience can confirm this ???), but for message based
modem case its going to call the release call request with cause value
Release by user, which will be translated to normal call clearing.
So in ofono core the hangup case for Incoming call should be handled in
same way as Waiting call by calling vc-driver-set_udub(vc,
generic_callback, vc);
instead of vc-driver-hangup(vc, generic_callback, vc);, so that UDUB
cause is sent to the remote party
BR,
Rajesh
From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf
Of Sankar
Sent: 01 October 2010 02:33
To: ofono@ofono.org
Subject: Query related to UDUB for voice calls.
Hi,
I was referring to the voice calls portion of ofono and I have a query
related to user determined user busy.
In the ofono core, if the user rejects a voice call, based on the call
status, respective driver function is called. I have pasted the code
below.
static DBusMessage *voicecall_hangup(
DBusConnection *conn,
DBusMessage *msg, void *data)
{
/* According to various specs, other than 27.007, +CHUP is
used
* to reject an incoming call
*/
if (call-status == CALL_STATUS_INCOMING) {
if (vc-driver-hangup == NULL)
return __ofono_error_not_implemented(msg);
vc-pending = dbus_message_ref(msg);
vc-driver-hangup(vc, generic_callback, vc);
return NULL;
}
if (call-status == CALL_STATUS_WAITING) {
if (vc-driver-set_udub == NULL)
return __ofono_error_not_implemented(msg);
vc-pending = dbus_message_ref(msg);
vc-driver-set_udub(vc, generic_callback, vc);
return NULL;
}
}
But as per the 3GPP TS 22001 v6.0.0, UDUB applies to an incoming call
also. Below is the excerpt from the specification.
C.3
User Determined User Busy (UDUB) condition
This condition occurs when a call is offered to a user equipment and the
UE responds user busy because the
subscribers resources (terminal or person using them) are busy. Then the
PLMN will clear the call with the indication
busy back towards the calling subscriber (see also clause 4).
Can some please clarify if the above behaviour in ofono core is proper
or this need to be corrected?
Thanks,
Sankar.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: Query related to UDUB for voice calls.
Hi Rajesh, Please, NO top posting on this list. On 10/01/2010 04:31 PM, rajesh.naga...@elektrobit.com wrote: Hi Sankar, My understanding is that when a call is rejected by the user, irrespective of whether its an incoming call or a waiting call, the cause value for the release call should be set to UDUB, so that for the remote subscriber the User Busy note will be shown in the UI if the voice mailbox is not configured. In the message based modem case, we set the cause value to UDUB with the release call request and in the AT based modem case we should send AT+CHLD=0, which will in turn set UDUB. So for the Incoming call hangup case if we call vc-driver-hangup(vc, generic_callback, vc); in AT case it will send AT+CHUP which i am not sure is inturn going to set the cause value to UDUB or not (Someone with AT based modem experience can confirm this ???), but for message based modem case its going to call the release call request with cause value Release by user, which will be translated to normal call clearing. So in ofono core the hangup case for Incoming call should be handled in same way as Waiting call by calling vc-driver-set_udub(vc, generic_callback, vc); instead of vc-driver-hangup(vc, generic_callback, vc);, so that UDUB cause is sent to the remote party Unfortunately AT modems do not allow any CHLD operations on incoming calls, including CHLD=0. CHLD=0 can only be used to set UDUB on waiting calls. To release incoming calls you must use ATH or +CHUP. Since AT command modems are the only ones described by 3GPP standards, that is the modem interface oFono assumes. If your modem deviates from this standard, then you need to make sure to send the proper release cause for incoming calls in the driver for your target hardware. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
