Comments (54)
I've already tried TCP with my provider but never with pbxes.org.
I was thinking TCP/UDP only acts on media transport but there is maybe a side
effect on registration process.
So I'll try it with pbxes.org in order to reproduce.
Thanks for the report.
Original comment by [email protected]
on 14 Jun 2010 at 9:45
- Changed state: Accepted
from csipsimple.
Unfortunately my proivder does not support TCP which requires me to use the
PBXes solution. I don't know if the combination Sipdroid/PBXes does something
non-standard in this case but the aim is to get a better standby time as
described by Sipdroid here
http://code.google.com/p/sipdroid/wiki/NewStandbyTechnique
Currently I get around 11 hours of standby on my Nexus One when CSipSimple is
running (using UDP and excluding any actual calls or other useage). That is
unfortunately a few hours too little for the phone to last a whole day on one
charge :(
Original comment by [email protected]
on 15 Jun 2010 at 11:09
from csipsimple.
Not sure this is specific to PBXes. From the logcat it appears the request is
never sent at all when TCP is choosen.
Logcat TCP output:
------------------
D/SIP SRV (11685): Get account infos....
D/libpjsip(11685): 14:18:44.423 pjsua_acc.c Account <sip:[email protected]>
added with id 0
I/SIP SRV (11685): Account pbxes.org ( 4 ) added as 0
D/SIP SRV (11685): Get account infos....
(and then many more Get account infos but not much more)
Equivalent UDP output:
----------------------
D/SIP SRV (11685): Get account infos....
D/libpjsip(11685): 14:22:22.254 pjsua_acc.c Account <sip:[email protected]>
added with id 0
D/libpjsip(11685): 14:22:22.255 pjsua_core.c TX 410 bytes Request msg
REGISTER/cseq=22956 (tdta0x37a108) to UDP XXX.XXX.XXX.XXX:5060:
D/libpjsip(11685): REGISTER sip:pbxes.com SIP/2.0
(and then lots of data)
Original comment by [email protected]
on 20 Jun 2010 at 1:23
from csipsimple.
You're absolutely right.
I didn't notice it but something has to be added in the registration uri to use
TCP transport. And previously pjsip stack doesn't care about it if only TCP
transport was created, that's the reason why I though my management of the
transport was already good.
Btw, if you want to try it with your current version, there is a workaround :
you add your account as an expert account and as "Registration URI" you add
";transport=tcp" at the end of the line.
For example :
"sip:pbxes.com;transport=tcp"
I'll try to find a smart way to add this parameter to registration uri
automatically if needed choosen in global preferences.
Original comment by [email protected]
on 20 Jun 2010 at 2:44
- Changed state: Started
from csipsimple.
Thanks :-) Doing this I can register using TCP and receive incomming calls
successfully. When I first tried outgoing calls they failed with the log:
W/libpjsip(13021): 18:44:02.473 tsx0x253c24 Failed to send Request msg
INVITE/cseq=31730 (tdta0x3a0bc8)! err=171060 (Unknown error 171060)
I had to add a proxy and the ";transport=tcp" parameter there as well to get it
to work for outgoing calls. The problem I am having now is that hangups don't
seem to be detected most of the time when I use this method.
Original comment by [email protected]
on 20 Jun 2010 at 6:04
from csipsimple.
Logcat seems to show same kind of problem, but now during hangup:
W/libpjsip(13021): 22:01:15.836 tsx0x58a17c Failed to send Request msg
BYE/cseq=21078 (tdta0x4f94b8)! err=171060 (Unknown error 171060)
I/SIP UA Receiver(13021): State of call 0 :: DISCONNECTED
Original comment by [email protected]
on 20 Jun 2010 at 8:30
from csipsimple.
From what I understand the intent of the ";transport:tcp" argument is to be
able to support multiple simultaneous transports and instructing pjsip to
choose tcp for this particular action.
http://trac.pjsip.org/repos/wiki/FAQ#tcp
In my case this whould be the preffered solution as I could register a
signaling TCP connection for incomming calls (through PBXes account) and when
making outbound calls I could use UDP (through my provider).
Whould it be possible to have another network transport option for "UDP and
TCP" which whould add both a UDP and a TCP transport during initialization? I
am assuming (without having looked) that this is how the pjsua application does
this.
Original comment by [email protected]
on 20 Jun 2010 at 11:12
from csipsimple.
You are absolutely right.
For now I create only one transport channel (its type is choosen by the network
setting).
I'll try to find a way to make a clear user interface that allow both basic
users to make a simple configuration and advanced users their custom
configuration.
I'll think on it. Your use case is very interesting, and that's true, it should
be supported by CSipSimple as an advanced configuration.
Original comment by [email protected]
on 20 Jun 2010 at 11:42
from csipsimple.
My use case is based on the assumption that the standby time will improve by
using a TCP connection for incomming calls. This seems to be the case as my
Nexus One lasts for several days without a charge when using Sipdroid with TCP
whereas when using UDP in Sipdroid/CSipSimple/SipAgent I never manage to get
more then around 12 hours on a charge.
This however requires that the Keep-Alive period for TCP can be changed to a
much higher value then the default used by pjsip (I think the default for pjsip
is set to 90 seconds). If the Sipdroid wiki page mentioned in above post is
correct then changing this Keep-Alive interval to say 3600 seconds should mean
much less power consumption for the phone in standby mode.
Is there any way set the Keep-Alive interval used by pjsip?
Original comment by [email protected]
on 22 Jun 2010 at 7:28
from csipsimple.
For now there is no field to change either keep-alive interval for accounts
registration (which is set at 15 seconds by default) or TCP keep alive time
(which is set at 90 seconds by default).
The first thing i'll do is give you a way to change this values.
Then when i'll be in the optimization step, i'll set this settings with
optimized values by default.
I'll keep you informed when i'll have a build with a way to change this values.
Original comment by [email protected]
on 22 Jun 2010 at 8:36
from csipsimple.
Regarding the problem with sending hangup when using TCP via PBXes. It seems
that PBXes does not respond correctly with the transport=tcp in the contact
which makes pjsip attempt to send BYE using UDP instead. I belive this is
incorrect behaviour on the part of PBXes.
I tested using sipsorcery instead which responds correctly. I then ran into
another problem which is when registering via TCP the NAT trick in pjsip does
not function as expected. During registration it detects the external ip:port
from the rport as expected but when it attempts the reregister it keeps using
the internal ip anyway and so it keeps looping forever during the registration
process. To get around this I recompiled pjsip without the freephonie hack and
then it works :-)
I also did a quick hack to add 2 transports at once (one UDP and one TCP) and
that seems to work very well, enabling me to activate both UDP and TCP at once
in the accounts using the advanced wizard.
Original comment by [email protected]
on 29 Jun 2010 at 8:58
from csipsimple.
Great.
So i'll remove freephonie hack from next builds. Seems to be useless in most
cases even with freephonie on production builds.
Ok for the 2 transports, great news. I'll try to implement something soon. Or
if you want to contribute on this subject, I can grant you an access on the svn.
On my side, what I've planned to implement is :
* One global settings choose the default transport TCP or UDP to use (if not specified in the wizard).
* Configuration for TCP (port) and configuration for UDP (port).
* Give access in expert and advanced mode (to be done) to an additional option that allow to choose between tcp and udp.
When sip stack is started if any account with tcp is present and active, it
starts tcp (and same thing with udp).
Finally, an evolution could be to allow user to add manually transports and
then choose one of these transports in the expert wizard. But in a first time
it is a little bit too complicated I think.
What do you think about such an implementation?
Original comment by [email protected]
on 29 Jun 2010 at 10:03
from csipsimple.
Sure I can contribute :-)
Since not all providers support TCP (most probably don't actually) it might be
enough to leave this up to the respective wizard. In expert mote it can be used
as it currently is with adding the parameter which seems to be standard in sip.
Network configuration can be extended with a "Enable TCP" and an "Enable UDP"
checkbox. And if enabled a port can then be choosen below. Default setting can
then be to enable both with port 5060.
CSipSimple also needs to send the user agent field when registering. I think
all that is needed is to set a user agent string in the config (ie something
like "CSipSimple" in cfg.user_agent). Seems sipsorcery does not grant the
requested re-registration value otherwise.
Original comment by [email protected]
on 2 Jul 2010 at 1:36
from csipsimple.
Micheal, can you send me by mail your google account address (so that I can
open the svn for you).
You can mail me at :
r3gis.3r at gmail.com
or
r3gis at r3gis.fr
Original comment by [email protected]
on 9 Jul 2010 at 10:20
from csipsimple.
FYI this is still a problem on 0.00-12 (with the 0.00-12 libpjsipjni.so). It
hangs trying to register. I have (the now separate) TCP enabled and UDP
disabled.
Original comment by [email protected]
on 15 Jul 2010 at 11:22
from csipsimple.
Which part is still a problem? The pjsip NAT re-registration or something else?
Have not had a chance to try 0.00-12 (or compile the lastest sources) yet but
from the changelist it looked good. I have used the older version without the
freephonie hack and works with at least the 3 providers I have tested with.
This is of course assuming that the provider supports TCP.
I am going to play around with the latest version once I get I chance this
weekend.
Original comment by [email protected]
on 16 Jul 2010 at 9:18
from csipsimple.
I don't know, and cannot at present diagnose. The registration just never
completes. I am sorry but I do not know what "NAT re-registration" is. It never
registers at all. It will register immediately with UDP.
Original comment by [email protected]
on 19 Jul 2010 at 11:03
from csipsimple.
Oh, I am sorry, this is with the trunk r149 and the 0.00-12 pjsip library.
Original comment by [email protected]
on 19 Jul 2010 at 11:04
from csipsimple.
I have built both pjsip and trunk and it works without problems for me so far.
With NAT-registration I mean when pjsip registers via SIP it looks at the rport
information in the received response to determine the external ip and port used
by the NAT firewall. There is a pretty good explanation of it here if you are
interested:
http://code.google.com/p/androidsipservice/wiki/NatTraversal
Original comment by [email protected]
on 19 Jul 2010 at 11:12
from csipsimple.
Wow, so complicated. I'm not even that familiar with the details of NAT. When I
can, though, I will take some traces and try to see what is failing. For now,
though, I have to attend to my real work getting ready for a conference later
this week :-(
Original comment by [email protected]
on 20 Jul 2010 at 12:59
from csipsimple.
Well, I looked at the traces, and even when I select ONLY TCP, the REGISTER is
still being done over UDP? And CSipSimple gets stuck at Registering. I do not
see any TCP traffic!
Furthermore, going back into network settings, then back out, does not result
in ANY traffic at all. Same with selecting Menu/Quit, then restarting the GUI.
No additional REGISTER traffic at all, and the account is still stuck at
Registering. Finally going into Network settings, turning off BOTH TCP and UDP,
back to phone. Account shows Error registering. Then back into Network
Settings, turn on ONLY TCP, still no more net traffic. Disabling and
re-enabling the account, again no additional net raffic.
At this point, going into Network Settings, turning off TCP, turning on UDP,
account immediately registers.
I don't know what all of this means, but hopefully you'll understand!
Original comment by [email protected]
on 26 Jul 2010 at 11:26
from csipsimple.
Sounds like you have not added the transport=tcp parameter. The TCP and UDP
transport settings only enable the actual transports. In order for TCP to be
used you still have to add ";transport=tcp" add the end to both the
registration uri and the proxy uri using expert mode.
This should work, provided your provider or server supports TCP connections.
Original comment by [email protected]
on 27 Jul 2010 at 7:52
from csipsimple.
Oh, I get it. Each account can be either TCP or UDP, and the checkboxes under
network only enable/disable TCP/UDP for the stack.
Question: Why not just -always- enable both TCP and UDP? Or said another way,
why would you want to disable one or the other (or both??) in addition to
selecting which transport a given account uses?
Original comment by [email protected]
on 27 Jul 2010 at 10:13
from csipsimple.
[deleted comment]
from csipsimple.
Ah, it's working! It is required to set up the Proxy as well as the Register
URI. Thank you!!
Original comment by [email protected]
on 27 Jul 2010 at 11:36
from csipsimple.
Should CSipSimple be originating on port 5060? It seems as though it is not
when using TCP (it does using UDP). Here is a capture of the REGISTER packet
(with auth info), this succeeds (200 OK):
Frame: Number = 2219, Captured Frame Length = 964, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP
(IPv4),DestinationAddress:[00-13-72-12-B0-70],SourceAddress:[00-0C-41-D3-8A-5C]
+ Ipv4: Src = 70.167.219.234, Dest = 70.167.219.233, Next Protocol = TCP,
Packet ID = 32734, Total IP Length = 950
+ Tcp: Flags=...AP..., SrcPort=53120, DstPort=5060, PayloadLen=898,
Seq=1459365844 - 1459366742, Ack=1159210590, Win=32044 (scale factor 0x1) =
64088
- SIP: Request: REGISTER sip:sip.dc3.com;transport=tcp SIP/2.0
- SipParser: Request: REGISTER sip:sip.dc3.com;transport=tcp SIP/2.0
- RequestLine: REGISTER sip:sip.dc3.com;transport=tcp SIP/2.0
Method: REGISTER
RequestURI: sip:sip.dc3.com;transport=tcp
SIPVersion: SIP/2.0
- RequestHeaders:
+ Via: SIP/2.0/TCP 70.167.219.234:53120;rport;branch=z9hG4bKPjlGthMHYy9GgSUt1dRuzgcwMMrL8CzL9Q
Route: <sip:sip.dc3.com;transport=tcp;lr>
Max-Forwards: 70
+ From: "Bob Android" <sip:[email protected]>;tag=H2XUAnblzIJIl03axaH8l18NshWhqeOX
+ To: "Bob Android" <sip:[email protected]>
CallID: kDVEFfeyWsQNOWw73M2pQ0p2QNNmQa-U
+ CSeq: 5898 REGISTER
User-Agent: CSipSimple
+ Contact: <sip:[email protected]:53120;transport=tcp>
+ Contact: "Bob Android" <sip:[email protected]:5060;transport=TCP>;expires=0
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
+ Authorization: Digest username="107", realm="3CXPhoneSystem", nonce="414d535c025fff6a81:691dd02cb9a04f803e67f6e87f61ba99", uri="sip:sip.dc3.com;transport=tcp", response="e62134452442673bc23ea54c729fea46", algorithm=MD5
ContentLength: 0
HeaderEnd: CRLF
Original comment by [email protected]
on 27 Jul 2010 at 11:43
from csipsimple.
I think this is correct behavior.
You are probably right that both UDP and TCP transports should be enabled by
default as for most cases this should never be changed. In the basic account
wizard it would be good to have a connection type selection were TCP or UDP can
then be selected for the account (with UDP being the default value), and this
whould then add the ";transport=tcp" parameter automatically if TCP is selected.
Original comment by [email protected]
on 28 Jul 2010 at 7:51
from csipsimple.
don't really know the difference but if you use sip2sip and have either both or
only tcp enabled, sip2sip wont connect...
Original comment by [email protected]
on 28 Jul 2010 at 8:55
from csipsimple.
Probably a result of the missing ;transport=tcp on the register URI as well as
the requirement for a proxy with the same thing (may be blank for TCP). This
one got me as well until michael helped me in Comment 22.
Michael - Why is a proxy necessary for TCP only? I just put the same thing into
the Proxy as the Registration URI. If I get time today I'll look at this to see
if it is just an omission in the code.
Original comment by [email protected]
on 28 Jul 2010 at 2:57
from csipsimple.
Michael -- On Comment 27, the settings say that the TCP Port selection is the
"Port number to bind locally". Same with UDP Port. But for TCP, that port is
not used, instead a temporary (high numbered) port is used. On UDP, however,
the specified port is used locally. You can see this in UDP packet traces,
where both the source and destination ports are 5060.
It may be a minor point though.
Original comment by [email protected]
on 28 Jul 2010 at 9:23
from csipsimple.
Well I believe this is how the pjsip stack behaves when it handles the
re-registration trick to bypass NAT using TCP. Not sure why it uses a random
port for the initial register though, but I think it also opens the local port
specified (5060) for incoming connections.
You can see the lines containing the old and the new contact from the capture:
+ Contact: <sip:[email protected]:53120;transport=tcp>
+ Contact: "Bob Android" <sip:[email protected]:5060;transport=TCP>;expires=0
Expires: 300
Original comment by [email protected]
on 28 Jul 2010 at 10:36
from csipsimple.
Took this one and am working on the TCP setting per-account.
Required revving the database to 7!
I have added a Use TCP checkbox to the account. Other hardcoded strings are now
resources. The ;transport=tcp is being added automatically (not needed in the
pref string any more), and if there is no proxy, it temporarily copies the Reg
Uri to Proxy then restores the or a Proxy exists, it adds 'transport=tcp to
that as well (and again reverts after registration). It's working for all
cases, but I have a few things to clean up yet.
Original comment by [email protected]
on 29 Jul 2010 at 3:48
- Added labels: Component-Logic, Component-UI
from csipsimple.
Michael and Regis --
From Comment 27: "You are probably right that both UDP and TCP transports
should be enabled by default as for most cases this should never be changed."
May I just remove the UDP and TCP preferences (keep the UDP Port and TCP
Port!), and the if() logic during sip startup, and ALWAYS create both
transports? Can you think of a reason one or the other transport would need to
be disabled globally (for all accounts)?
I would like to remove them, as it is a confusing point between those prefs and
the new Use TCP pref in the account. If the global ones (network prefs) must
stay, then I must find a way to handle the situation where the account
selection (TCP/UDP) is not enabled in network prefs. I dislike the idea of
toast popups for such things.
Original comment by [email protected]
on 29 Jul 2010 at 7:39
from csipsimple.
Right now only Expert accounts have the TCP option. Which of the SIP providers
do NOT support TCP? I'm trying to decide where to implement the Use TCP
checkbox logic. Should it be in SimplePrefsWizard? Or in each provider wizard?
Should it be in Basic (not a child of SimplePrefsWizard)?
Original comment by [email protected]
on 29 Jul 2010 at 7:46
from csipsimple.
Due to the database version change, I decided to commit r168. Awaiting answers
to finish this one.
Original comment by [email protected]
on 29 Jul 2010 at 7:54
from csipsimple.
Actually I think it should be the other way around. For Expert mode it would be
best to keep the settings as close as possible to the way they are in pjsip. If
I am an expert then I have the ability to write the transport parameter myself
which is part of the SIP standard way.
For basic account I think there should be the option to choose TCP/UDP with UDP
being default.
Leave the transport settings as they are except also enable TCP by default. The
pjsip reference application pjsua has options to specify "no-tcp" and "no-udp"
so I think we should assume there are reasons to keep this setting. I also
don't think you have to add any check when setting the transport parameter in
the wizard. If someone explicitly disables TCP we have to assume they know that
an account using TCP will not register.
Original comment by [email protected]
on 29 Jul 2010 at 8:12
from csipsimple.
I agree Micheal, we should leave expert as managed by pjsip (could save time
for pjsip experts to test new features from the pjsip stack).
I think we should add an account wizard "Advanced" that allow to activate tcp.
I'd like Basic wizard to be a really simple way for mainstream users to quickly
add an account. Then if they want to, they will be able to transform the Basic
wizard into the Advanced one and activate TCP. Besides, I hope that we will
create enough wizards for each provider and activate automatically tcp for
providers that support it.
Bob, as you added a field in the database, you should implement "public void
onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) " from DBAdapter.
Take a look on how I did things for KA_INTERVAL field. Should be the same way
to update the db for users how have already CSipSimple installed and want to
keep their account configuration (this applies to the market version).
For the last point (transport). What about my suggestion? Activate tcp only if
one of the active account has transport=tcp or tcp activated in database? And
do the same for udp? If this can be automatically detected, there is no reason
to ask the user to choose. Isn't it?
Original comment by [email protected]
on 29 Jul 2010 at 9:01
from csipsimple.
I think enabling both transports by default will be sufficient for 99% of the
cases. I actually think this is the required standard behavior according to the
RFC (although probably very few clients actually implement it this way).
Meaning that even if the client does not specify TCP the server can still
decide to use it, which is also the reason to keep the ability to explicitly
disable a specific transport.
The Advanced wizard is a good idea, as a first we could just copy the basic
wizard and add the transport parameter, register timeout and keep-alive timeout
values.
Original comment by [email protected]
on 29 Jul 2010 at 9:34
from csipsimple.
Ok, I understand why activating tcp by default should be done.
So you're right if server can decide to choose tcp, we must enable it by
default.
It could be a good idea to make tests with / without the transport enabled
(without any account registered) to know what is the impact on battery usage of
a extra transport.
Code has to be modified to allow this test since if there is no account remote
pjsip is shut down - maybe should we allow "local" accounts? -
Theses tests could be provide as a wiki documentation to explain what parameter
can be modified to reduce battery usage (or set as default parameters according
accounts and/or device).
I'm looking for something to trace exactly the battery usage with more
precision than the android tool (which seems to not take into account native
library - or if yes... it means that csipsimple take about 3% of the battery
after a full day of use..... I don't think so....).
Any idea?
P.S. : for advanced, we can also add sip proxy field, display name (optional)
and authentication name (optional - leave blank will reuse the username field).
Original comment by [email protected]
on 29 Jul 2010 at 9:54
from csipsimple.
Yes definately need to do some tests. Especially since battery life is the main
argument for using TCP at all.
Original comment by [email protected]
on 29 Jul 2010 at 10:18
from csipsimple.
Regis: "Bob, as you added a field in the database, you should implement "public
void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) " from
DBAdapter. Take a look on how I did things for KA_INTERVAL field. Should be the
same way to update the db for users how have already CSipSimple installed and
want to keep their account configuration (this applies to the market version)."
I did this. While I was at it, I refactored the code:
if(oldVersion < 1) {
db.execSQL("DROP TABLE IF EXISTS " + ACCOUNTS_TABLE_NAME);
} else if(oldVersion < 7) {
if(oldVersion < 5)
db.execSQL("ALTER TABLE "+ACCOUNTS_TABLE_NAME+" ADD "+Account.FIELD_KA_INTERVAL+" INTEGER");
if(oldVersion < 6)
db.execSQL("DROP TABLE IF EXISTS "+FILTERS_TABLE_NAME);
db.execSQL("ALTER TABLE "+ACCOUNTS_TABLE_NAME+" ADD "+Account.FIELD_USE_TCP+" BOOLEAN");
}
Original comment by [email protected]
on 29 Jul 2010 at 1:54
from csipsimple.
Completed, see r169 and r170 (for log, sorry). I did my best to accommodate the
desires of you all. I think it is working in a way that will make it easy to
maintain and keep repeated code out of the wizards.
Original comment by [email protected]
on 30 Jul 2010 at 12:08
- Changed state: Fixed
from csipsimple.
Back to Started status, for some reason I can't get it to register via TCP this
morning!
Original comment by [email protected]
on 30 Jul 2010 at 1:46
- Changed state: Started
from csipsimple.
Turned out to be problems with my SIP server. Will do more testing.
Original comment by [email protected]
on 30 Jul 2010 at 5:41
from csipsimple.
Looks fine now -> Fixed
Original comment by [email protected]
on 30 Jul 2010 at 8:25
- Changed state: Fixed
from csipsimple.
I am using DEV 13-02 with HTC Hero VillainRom 12 and FreePBX 2.8. I am
registering successfully wit TCP on 3G but when I switch to wifi the
registration times out. Any ideas?
Original comment by [email protected]
on 1 Oct 2010 at 3:49
from csipsimple.
My bad. I changed to TCP after registering via UDP so connection stayed from
previous session. At this point I am not sure our system is not configured
properly for TCP.
Original comment by [email protected]
on 1 Oct 2010 at 7:10
from csipsimple.
However, there is still problem with tcp...
I'm currently trying to understand how to use properly pjsip to make it working
flawlessly with TCP.
As I'm currently implementing TLS & SRTP, I'm understanding many things ;)
Original comment by [email protected]
on 1 Oct 2010 at 7:17
from csipsimple.
I fixed my PBX config and now have HTC Hero Villainrom 12 running on TCP. So
far so good.
Original comment by [email protected]
on 3 Oct 2010 at 3:18
from csipsimple.
ok guys i am have this problem with tcp only , we are in 2012 is this been fix
or we still need to add the transport line ???
where do we change the time UDP look for registration to 90 sec like tcp does ?
thanks
sly
Original comment by [email protected]
on 19 Feb 2012 at 5:55
from csipsimple.
Sylvain, this issue is really really obsolete.
Maybe you should open a new issue or ask on the user mailing list if you have
an issue.
About, the registration time it does not depends on the transport kind at all.
So it's in the expert wizard account mode. If you mean the keep alive time,
it's in global settings (network) also in expert setting mode. (See the
ExpertSettingMode wiki page).
In nightly build there is also the option for tcp keep alive (and the market
version contains the option for udp only).
Then if you have a more detailed description you can open a new issue. Please
take care to specify your sip provider. Not all sip providers does actually
support correctly TCP. In this case it's not the client application to blame
but your sip provider ;)
Original comment by [email protected]
on 19 Feb 2012 at 7:56
from csipsimple.
i use pbxes and from my test and what is in this thread, pbxes need UDP to
register, but since this thread dated from july 2010 , i was asking if we still
need to add the transporttcp line and you also mention UDP was sending packet
every 20 sec cmpare to tcp 90 sec , so if we can change the setting for udp
will it help the battery to not drain so fast? if i activate tcp and udp will
csipsimple use the udp to register only and when receiving or making call will
it use tcp ?
thanks
sly
Original comment by [email protected]
on 19 Feb 2012 at 10:47
from csipsimple.
i post it in a new thread as ask
Original comment by [email protected]
on 19 Feb 2012 at 10:52
from csipsimple.
I think TCP is bugged for sip on every android 4.*.*
Original comment by [email protected]
on 6 Jun 2013 at 7:02
from csipsimple.
Related Issues (20)
- PSP Wifi mode : Sound becomes choppy/garbled when the phone goes to sleep in mid-call HOT 22
- After SIP call, next GSM call starts in "Loudspeaker" mode HOT 4
- sip outgoing only - result crash when dialing HOT 2
- Ability to put call on HOLD HOT 3
- Register timeout always reverts to 15 sec (Expert account wizard) HOT 15
- Keep-Alive Interval always reverts to blank (0) HOT 1
- Expert wizard: Data Type not initialized with account DB value HOT 12
- pre5 - Cannot disable or change Keep-Alive HOT 8
- Cannot erase Proxy URI field once it has been filled in HOT 2
- Enhancement: Account wizard for Callcentric HOT 5
- Battery consumption HOT 143
- Micro / Speaker booster option HOT 1
- Cannot dial USSD codes while CSipSimple installed HOT 19
- new account HOT 2
- Phone calls do not pause media HOT 30
- No audio / Poor audio on Nexus One HOT 15
- Account Status Labels - More Descriptive and Localizable HOT 3
- Account name not shown on X10 Mini HOT 9
- [Manufacturer driver] Echo on Xperia X10 HOT 16
- Connect to SIP provider only on specific WiFi network
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from csipsimple.