Query related to UDUB for voice calls.

Query related to UDUB for voice calls.

[Sankar]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

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.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1873 bytes --]

RE: Query related to UDUB for voice calls.

[Rajesh.Nagaiah]

[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]

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-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On Behalf
Of Sankar
Sent: 01 October 2010 02:33
To: ofono(a)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. 

Re: Query related to UDUB for voice calls.

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

Hi Rajesh,

Please, NO top posting on this list.

On 10/01/2010 04:31 PM, Rajesh.Nagaiah(a)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

Re: Query related to UDUB for voice calls.

[Sankar]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

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 <denkenz@gmail.com> wrote:

> Hi Rajesh,
>
> Please, NO top posting on this list.
>
> On 10/01/2010 04:31 PM, Rajesh.Nagaiah(a)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(a)ofono.org
> http://lists.ofono.org/listinfo/ofono
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3034 bytes --]

Re: Query related to UDUB for voice calls.

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

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