Failed to register using TCP

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Requires an account with pbxes.org 
2. Use the basic account wizard in CSipSimple to access pbxes.org
3. Change the settings to use TCP
4. Attempt to register, status only says "In progress"

What is the expected output? What do you see instead?
A successfull registration enabling incomming and outgoing calls to be made.

What version of the product are you using? On what operating system?
0.00-11 on Nexus One (with Android 2.2)

Please provide any additional information below.
I usually use a setup using TCP with pbxes.org in order to consume battery. 
This works in Sipdroid but I have not managed to register CSipSimple with 
pbxes.org using TCP. With UDP it works fine in CSipSimple.

Original issue reported on code.google.com by michael....@gmail.com on 12 Jun 2010 at 8:45

[GoogleCodeExporter]

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 r3gis...@gmail.com on 14 Jun 2010 at 9:45

• Changed state: Accepted

[GoogleCodeExporter]

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 michael....@gmail.com on 15 Jun 2010 at 11:09

[GoogleCodeExporter]

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:xxxxxx@pbxes.com> 
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:xxxxxx@pbxes.com> 
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 michael....@gmail.com on 20 Jun 2010 at 1:23

[GoogleCodeExporter]

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 r3gis...@gmail.com on 20 Jun 2010 at 2:44

• Changed state: Started

[GoogleCodeExporter]

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 michael....@gmail.com on 20 Jun 2010 at 6:04

[GoogleCodeExporter]

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 michael....@gmail.com on 20 Jun 2010 at 8:30

[GoogleCodeExporter]

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 michael....@gmail.com on 20 Jun 2010 at 11:12

[GoogleCodeExporter]

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 r3gis...@gmail.com on 20 Jun 2010 at 11:42

[GoogleCodeExporter]

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 michael....@gmail.com on 22 Jun 2010 at 7:28

[GoogleCodeExporter]

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 r3gis...@gmail.com on 22 Jun 2010 at 8:36

[GoogleCodeExporter]

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 michael....@gmail.com on 29 Jun 2010 at 8:58

[GoogleCodeExporter]

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 r3gis...@gmail.com on 29 Jun 2010 at 10:03

[GoogleCodeExporter]

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 michael....@gmail.com on 2 Jul 2010 at 1:36

[GoogleCodeExporter]

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 r3gis...@gmail.com on 9 Jul 2010 at 10:20

[GoogleCodeExporter]

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 dc3de...@gmail.com on 15 Jul 2010 at 11:22

[GoogleCodeExporter]

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 michael....@gmail.com on 16 Jul 2010 at 9:18

[GoogleCodeExporter]

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 dc3de...@gmail.com on 19 Jul 2010 at 11:03

[GoogleCodeExporter]

Oh, I am sorry, this is with the trunk r149 and the 0.00-12 pjsip library.

Original comment by dc3de...@gmail.com on 19 Jul 2010 at 11:04

[GoogleCodeExporter]

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 michael....@gmail.com on 19 Jul 2010 at 11:12

[GoogleCodeExporter]

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 dc3de...@gmail.com on 20 Jul 2010 at 12:59

[GoogleCodeExporter]

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 dc3de...@gmail.com on 26 Jul 2010 at 11:26

[GoogleCodeExporter]

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 michael....@gmail.com on 27 Jul 2010 at 7:52

[GoogleCodeExporter]

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 dc3de...@gmail.com on 27 Jul 2010 at 10:13

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ah, it's working! It is required to set up the Proxy as well as the Register 
URI. Thank you!!

Original comment by dc3de...@gmail.com on 27 Jul 2010 at 11:36

[GoogleCodeExporter]

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:107@sip.dc3.com>;tag=H2XUAnblzIJIl03axaH8l18NshWhqeOX
    + To: "Bob Android" <sip:107@sip.dc3.com>
      CallID: kDVEFfeyWsQNOWw73M2pQ0p2QNNmQa-U
    + CSeq: 5898 REGISTER
      User-Agent: CSipSimple
    + Contact: <sip:107@70.167.219.234:53120;transport=tcp>
    + Contact: "Bob Android" <sip:107@192.168.0.120: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 dc3de...@gmail.com on 27 Jul 2010 at 11:43

[GoogleCodeExporter]

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 michael....@gmail.com on 28 Jul 2010 at 7:51

[GoogleCodeExporter]

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 alessand...@gmail.com on 28 Jul 2010 at 8:55

[GoogleCodeExporter]

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 dc3de...@gmail.com on 28 Jul 2010 at 2:57

[GoogleCodeExporter]

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 dc3de...@gmail.com on 28 Jul 2010 at 9:23

[GoogleCodeExporter]

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:107@70.167.219.234:53120;transport=tcp>
    + Contact: "Bob Android" <sip:107@192.168.0.120:5060;transport=TCP>;expires=0
      Expires: 300

Original comment by michael....@gmail.com on 28 Jul 2010 at 10:36

[GoogleCodeExporter]

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 dc3de...@gmail.com on 29 Jul 2010 at 3:48

• Added labels: Component-Logic, Component-UI

[GoogleCodeExporter]

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 dc3de...@gmail.com on 29 Jul 2010 at 7:39

[GoogleCodeExporter]

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 dc3de...@gmail.com on 29 Jul 2010 at 7:46

[GoogleCodeExporter]

Due to the database version change, I decided to commit r168. Awaiting answers 
to finish this one.

Original comment by dc3de...@gmail.com on 29 Jul 2010 at 7:54

[GoogleCodeExporter]

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 michael....@gmail.com on 29 Jul 2010 at 8:12

[GoogleCodeExporter]

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 r3gis...@gmail.com on 29 Jul 2010 at 9:01

[GoogleCodeExporter]

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 michael....@gmail.com on 29 Jul 2010 at 9:34

[GoogleCodeExporter]

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 r3gis...@gmail.com on 29 Jul 2010 at 9:54

[GoogleCodeExporter]

Yes definately need to do some tests. Especially since battery life is the main 
argument for using TCP at all.

Original comment by michael....@gmail.com on 29 Jul 2010 at 10:18

[GoogleCodeExporter]

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 dc3de...@gmail.com on 29 Jul 2010 at 1:54

[GoogleCodeExporter]

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 dc3de...@gmail.com on 30 Jul 2010 at 12:08

• Changed state: Fixed

[GoogleCodeExporter]

Back to Started status, for some reason I can't get it to register via TCP this 
morning!

Original comment by dc3de...@gmail.com on 30 Jul 2010 at 1:46

• Changed state: Started

[GoogleCodeExporter]

Turned out to be problems with my SIP server. Will do more testing.

Original comment by dc3de...@gmail.com on 30 Jul 2010 at 5:41

[GoogleCodeExporter]

Looks fine now -> Fixed

Original comment by dc3de...@gmail.com on 30 Jul 2010 at 8:25

• Changed state: Fixed

[GoogleCodeExporter]

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 dcitele...@gmail.com on 1 Oct 2010 at 3:49

[GoogleCodeExporter]

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 dcitele...@gmail.com on 1 Oct 2010 at 7:10

[GoogleCodeExporter]

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 r3gis...@gmail.com on 1 Oct 2010 at 7:17

[GoogleCodeExporter]

I fixed my PBX config and now have HTC Hero Villainrom 12 running on TCP. So 
far so good.

Original comment by dcitele...@gmail.com on 3 Oct 2010 at 3:18

[GoogleCodeExporter]

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 sylvain....@gmail.com on 19 Feb 2012 at 5:55