#50 Failed to register using TCP

[Anonymous]

Originally created by: michael....@gmail.com
Originally owned by: dc3de...@gmail.com

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.

[Anonymous]

Originally posted by: r3gis...@gmail.com

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.

Owner: r3gis.3R
Status: Accepted

[Anonymous]

Originally posted by: michael....@gmail.com

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
https://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  :(

[Anonymous]

Originally posted by: michael....@gmail.com

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)

[Anonymous]

Originally posted by: r3gis...@gmail.com

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.

Status: Started

[Anonymous]

Originally posted by: michael....@gmail.com

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.

[Anonymous]

Originally posted by: michael....@gmail.com

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

[Anonymous]

Originally posted by: michael....@gmail.com

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.

[Anonymous]

Originally posted by: r3gis...@gmail.com

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.

[Anonymous]

Originally posted by: michael....@gmail.com

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?

[Anonymous]

Originally posted by: r3gis...@gmail.com

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.

[Anonymous]

Originally posted by: michael....@gmail.com

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.

[Anonymous]

Originally posted by: r3gis...@gmail.com

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?

[Anonymous]

Originally posted by: michael....@gmail.com

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.

[Anonymous]

Originally posted by: r3gis...@gmail.com

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

[Anonymous]

Originally posted by: dc3de...@gmail.com

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.

[Anonymous]

Originally posted by: michael....@gmail.com

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.

[Anonymous]

Originally posted by: dc3de...@gmail.com

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.

[Anonymous]

Originally posted by: dc3de...@gmail.com

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

[Anonymous]

Originally posted by: michael....@gmail.com

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:
https://code.google.com/p/androidsipservice/wiki/NatTraversal

[Anonymous]

Originally posted by: dc3de...@gmail.com

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 :-(

[Anonymous]

Originally posted by: dc3de...@gmail.com

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!

[Anonymous]

Originally posted by: michael....@gmail.com

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.

[Anonymous]

Originally posted by: dc3de...@gmail.com

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?

[Anonymous]

Originally posted by: dc3de...@gmail.com

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

[Anonymous]

Originally posted by: dc3de...@gmail.com

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