Closed GoogleCodeExporter closed 9 years ago
This appears to be the expected behavior.
Original comment by pmerl...@googlemail.com
on 5 Jun 2009 at 6:56
This is not an answer. If this is the expected behavior then it is a stupid
design
flaw. Perhaps, there is some misunderstanding of what the problem is. First of
all,
the flag says use sip WHEN AVAILABLE, i.e. if sip is available then use sip, if
not
use PSTN. Instead, the program totally takes over the dialer and it is
impossible to
make a normal call to a normal number unless I either toggle that flag to PSTN
or
kill the sip client. I would think that NORMAL behavior should be that when I
use the
program to dial and use a sip address it uses sip, if I use a regular telephone
number which the sip client can access using sip, then use sip. But if I simply
use
the dialer outside the sipdroid program I should be able to make a regular call
without sipdroid trapping my call, neither being able to make the call itself
nor
allowing me to just use the regular T-Mobile network unless I toggle that flag.
I certainly cannot run this program in this way 24/7 and worry that if I have
to make
an emergency call to 911 (for example) the damn program would block it and I
would
have to waste time toggling that flag or killing the process.
Original comment by pensive....@gmail.com
on 6 Jun 2009 at 3:53
The preference setting is only relevant for the dialer. So if you don't want
Sipdroid
to intercept it set it to PSTN. You can still can numbers from Sipdroid.
Second, you can still choose to call over SIP or PSTN (see FAQ).
And third, emergency calls always go over PSTN.
Original comment by pmerl...@googlemail.com
on 6 Jun 2009 at 7:31
What @pensive.introvert is referring to is
1. When preference setting is "SIP when availabe" the default behaviour for
emergency
calls should be PSTN (as opposed to the current behaviour of first trying SIP).
There maybe cases where SIP providers are not compliant with emergency numbers.
2. Use sipdroid only when dialing from within Sipdroid (as opposed to current
default
behaviour of sipdroid or pstn). This third preference would allow the user to
decide
how much control he/she wants to give to sipdroid for outgoing calls.
Original comment by wavehill09@gmail.com
on 7 Jun 2009 at 4:29
[deleted comment]
1. See revision comment.
2. Can you please elaborate more on what third preference should be. When
choosing
PSTN as preference it is still possible to dial over SIP from the Sipdroid
input
field as it is now.
Original comment by pmerl...@googlemail.com
on 8 Jun 2009 at 7:27
The third preference would be for fine grained interception of outgoing calls by
sipdroid. This request would be similar to the requests of Issue 11.
Original comment by wavehill09@gmail.com
on 8 Jun 2009 at 11:11
If it is not possible to implement the fine grained control (suggested above)
immediately for lack of time then at least a flag which tells the sipdroid to
keeps
its hands off the regular dialer and apply sip versus pstn preferences only when
dialing directly from the program.
Original comment by pensive....@gmail.com
on 9 Jun 2009 at 12:02
That flag as has been said before is to set preference to PSTN and then there
is no
interception of outgoing calls by sipdroid.
Original comment by wavehill09@gmail.com
on 9 Jun 2009 at 1:34
Original comment by pmerl...@googlemail.com
on 9 Jun 2009 at 8:07
Original comment by pmerl...@googlemail.com
on 16 Jun 2009 at 12:35
Could Sipdroid be made to affect the long press on a certain number for a
contact?
ie, when I long press on Call Mobile or Call Home for a contact, it bring up a
choice
similar to
http://code.google.com/p/sipdroid/wiki/FAQ#How_can_I_dial_my_contacts_over_IP_/_
over_PSTN?
The behavior as above is somewhat counterintuitive, since I naturally want to
select
Messaging as the default for the Text Mobile option, but then I cannot override
the
call type.
When viewing a contact, it would be great if tap just dialed according to
preferred
call type, but long press presented the override options.
Just a thought.
Original comment by brendan....@gmail.com
on 17 Jun 2009 at 7:19
Original comment by pmerl...@googlemail.com
on 19 Jun 2009 at 8:44
Original issue reported on code.google.com by
pensive....@gmail.com
on 5 Jun 2009 at 5:58