asterisk users - Mar 2016 - Mobiles not detecting as BUSY until Dial() timeout completes

I'm not sure if this is an Asterisk thing, a handset thing or a telco thing,
so please be gentle with me if this is not the right place to ask .....

When placing a call over a SIP channel to a mobile phone, if the phone is 
engaged, it does not return a BUSY status straightaway.  Rather, I get a 
ringing-out tone for the timeout duration specified in the Dial() statement; 
*then* I get ${DIALSTATUS}=BUSY.

Now, given how far we have moved on since the days of clicky-clicky exchanges, 
it is entirely possible that the mobile phone implicitly supports multiple 
"lines", so you can put an existing caller on hold, talk to the new
caller and
then switch between them as long as they stay on the line .....  in which 
case, this behaviour is pretty much what should be expected -- Asterisk 
doesn't know for sure that the remote party really is engaged, because they 
retain the option to put their call on hold and answer you, so it lets the 
timeout run; then, since they were already on a call at the time the first 
signalling message was sent, it sets the dialstatus to BUSY.


Where should I be looking, if I want to reproduce the "old-fashioned" 
behaviour and return an engaged signal straight away?

-- 
AJS

Note:  Originating address only accepts e-mail from list!  If replying off-
list, change address to asterisk1list at earthshod dot co dot uk .

In article <201603241343.24128.asterisk_list at earthshod.co.uk>,
A J Stiles <asterisk_list at earthshod.co.uk>
wrote:
> I'm not sure if this is an Asterisk thing, a handset thing or a telco
thing,
> so please be gentle with me if this is not the right place to ask .....
> 
> When placing a call over a SIP channel to a mobile phone, if the phone is 
> engaged, it does not return a BUSY status straightaway.  Rather, I get a 
> ringing-out tone for the timeout duration specified in the Dial()
statement;
> *then* I get ${DIALSTATUS}=BUSY.
> 
> Now, given how far we have moved on since the days of clicky-clicky
exchanges,
> it is entirely possible that the mobile phone implicitly supports multiple 
> "lines", so you can put an existing caller on hold, talk to the
new caller and
> then switch between them as long as they stay on the line .....  in which 
> case, this behaviour is pretty much what should be expected -- Asterisk 
> doesn't know for sure that the remote party really is engaged, because
they
> retain the option to put their call on hold and answer you, so it lets the 
> timeout run; then, since they were already on a call at the time the first 
> signalling message was sent, it sets the dialstatus to BUSY.
> 
> 
> Where should I be looking, if I want to reproduce the
"old-fashioned"
> behaviour and return an engaged signal straight away?
Sounds like the mobile line has Call Waiting enabled, and the waiting call
has been ignored by the recipient until it times out.

See https://en.wikipedia.org/wiki/Call_waiting and try *#43# on the mobile
in question to check whether call waiting is active. Use #43# to try
deactivating it and see if that helps.

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org

On Thursday 24 Mar 2016, Tony Mountifield wrote:
> In article <201603241343.24128.asterisk_list at earthshod.co.uk>,
> A J Stiles <asterisk_list at earthshod.co.uk> wrote:
> > When placing a call over a SIP channel to a mobile phone, if the phone
is
> > engaged, it does not return a BUSY status straightaway.  Rather, I get
a
> > ringing-out tone for the timeout duration specified in the Dial()
> > statement; *then* I get ${DIALSTATUS}=BUSY.
> Sounds like the mobile line has Call Waiting enabled, and the waiting call
> has been ignored by the recipient until it times out.
Yes, that was what I was suspecting.  Although, the handset I'm using
didn't
appear to acknowledge the second call.

Anyway, at least you gave me somewhere to dig .....

Querying with *#43#  (same as BT landline)  brought up a message that Call 
Waiting was deactivated.  I turned it on with *43# and was then able to switch 
back and forth between two callers.

Then I asked someone else, who noticed I was using the "r" option in
my Dial()
statement and suggested removing this.  I turned Call Waiting off again with 
#43# and tried again.  The handset from which I was calling still gave a 
ringing-out tone.  But once this was answered, a further call stopped short at 
the Dial() statement and went straight to the h extension, instead of moving 
onto the next step  (here just a NoOp to display the value of ${DIALSTATUS})  
as though the call had been answered.


Is there something I am missing, or should I be looking towards the telco?


N.B.  I'm actually using realtime config to get the dialplan from a
database;
but this is what it would look like if it was written directly in 
extensions.conf.  The AGI script at step 2 is required because when the call 
comes from a mobile phone, the telco are actually sending the originating SIM 
ID  (the long number that begins with 8944.....)  in ${CALLERID(num)}, not the 
actual mobile phone number.  And the Dial() also should be directed to the 
destination SIM ID.

1,NoOp(Call from ${CALLERID(num)})
2,AGI(lookup_caller_id.agi,${CALLERID(num)})
3,NoOp(Caller ID should be ${clid})
4,Set(CALLERID(num)=${clid})
5,Macro(record-on)
6,Dial(${TELCO}/${DEST_SIM_ID},45)
7,ExecIf($["${DIALSTATUS}"="BUSY"]?VoiceMail(${EXTEN},b):VoiceMail(${EXTEN},u))
8,HangUp()


-- 
AJS

Note:  Originating address only accepts e-mail from list!  If replying off-
list, change address to asterisk1list at earthshod dot co dot uk .
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20160324/68d3e515/attachment.html>