TCP: Cannot receive calls

[klaidlaw]

Ipod touch 4th gen; absolute latest Bria iphone (2.0.0) with presence. Registers over same lan segment to sipX 4.4.0 using UDP. Confirm all works well.

Now let's try to help that battery. Change to TCP from UDP. This is the ONLY change. Registration works. Outgoing calls perfect. Oops. No incoming calls. They go straight to VM at sipX. Note that sipX DOES support TCP and the registration was OK and still active at sipX.

More info: X-lite on my laptop works perfectly incoming and outgoing with TCP. X-lite registers with expires=3600 then immediately follows with register of expires=0. Bria registers with expire=3600 and then "Subscribes" (i.e. a bit different).

I've seen others say no incoming and think it may be the same problem. Could be some config or other, or an incompatibility between Bria Iphone and sipX.

Anyone have any insight? If so, I can provide way more detail, but I suspect there is some guru out there who knows exactly what is wrong (and how to fix it).

To this guru and anyone else who can help, TIA

Keith

[Bogdan]

U cannot compare TCP of iOS and x-lite (Win/MAC). Totally different rules (imposed by Apple).

There are in general 2 sticky issues that might TCP not work on iOS:
1. Active expire for REGISTER is less than ~600s.
2. Server does not reuse TCP connection (as it should) but tries to establish new incoming connection to the client.

Perhaps Sending Log from the app will give more data? With the ref# here.

[klaidlaw]

1) I can totally rule out the register < 600s. I know about the 10 minute rule (and even if I didn't, Bria sure reminds me!)
2) Not reusing the TCP connection of the register. Hmm. Could very well be the key. I didn't think it was an RFC requirement to reuse the connection. I'll check appropriate logs.

Thanks for your straightforward and informative reply.

[Bogdan]

This is a paste from other related post:

"For connection based transports, the SIP server should reuse the TCP connection initiated by Bria. In most deployments for mobile services, there will be a NAT or firewall between Bria and the SIP server. NAT and firewall will prevent the SIP server to connect to Bria's listen TCP socket anyways.

Most SIP servers already reuse the TCP connection initiated by Bra. Unfortunately this best practice was not defined in the SIP 2.0 RFC 3261 spec.

However RFC 5626 spec does define behavior for user agents behind NAT and firewalls in reusing TCP and TLS connections. From the introduction:

There are many environments for SIP [RFC3261] deployments in which
the User Agent (UA) can form a connection to a registrar or proxy but
in which connections in the reverse direction to the UA are not
possible. This can happen for several reasons, but the most likely
is a NAT or a firewall in between the SIP UA and the proxy. Many
such devices will only allow outgoing connections. This
specification allows a SIP User Agent behind such a firewall or NAT
to receive inbound traffic associated with registrations or dialogs
that it initiates."

[klaidlaw]

I registered then made a call and the register contains the following:

"REGISTER sip:laidlaw.private SIP/2.0
Via: SIP/2.0/TCP
192.168.7.131:49487;rport;branch=z9hG4bKPjzZnBwF3yd8fNPtG0QE szLP72vl12faa1;alias

Max-Forwards: 70
From: "Brooke iPod"
< sip:204@laidlaw.private>;tag=D.ujLLC78Fe0FLw3YQKnNf35VKEsVpMi
To: "Brooke iPod" <sip:204@laidlaw.private>
Call-ID: DzvrhVhBFmSZW3I.0RLiy6r8jhtwDSRf
CSeq: 49097 REGISTER
User-Agent: Bria iOS 2.0.0
Contact: "Brooke iPod" <sip:204@192.168.7.131:49486;transport=TCP>
Expires: 600
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Content-Length: 0"

Note that the VIA and Contact: lines have different TCP ports. Who (UA, Proxy or Registrar) chooses each of the two? Why would they be different (all devices are on the same subnet). Could this be the problem?

If this is the problem, how do I correct it? Is Bria always expecting some form of NAT correction even if they are on the same subnet? Even if the problem is not the UA, can I "trick" it somehow?

Keith

[klaidlaw]

Actually, I looked at the trace and found out that the UA (Bria) is the author of both lines (the via and the contact). Why would Bria choose to make the port number on the contact line one count less than the TCP port it was actually using? I'm not perfectly fluent in SIP, but I think the via line is uses to know where to send replies (e.g. a 200 reply to a register) and the contact line is used to tell the proxy how to contact the UA (e.g. with an INVITE). If that is the case, how could incoming calls work at all (which I'm sure it does for others)?

Keith

[Bogdan]

There should be settings somewhere on server not to open new connection to ua, but to reuse. It could be a complex thing if other entities e.g. SBC are involved.
There is iOS limitations that when in voip app in BG, incoming connections cannot be properly processed by the OS.
So we are relying on the practice of the connection reuse. This is add-on to the basic RFC you (and I) were quoting.
I'm looking right at somehow make it more robust. Details might follow.

Looks like Apple developed the TCP BG support taking at primary use case Skype. They might ignored the SIP case that when no TLS or NAT then there could be incoming connection... All this stuff is not documented by Apple.

[klaidlaw]

Actually, I'm pretty sure the server would be happy not to open a new connection, but Bria is telling it to use a different port when contacting! Why wouldn't the contact port (specified by Bria during the REGISTER) be the same port it registered on? If I hear you correctly, that's what Bria wants (i.e. use the same port to contact - or INVITE - as to REGISTER) but it is telling the proxy to do something different (use a port one less to contact).

Am I misinterpreting the contact line?

[klaidlaw]

Ran some tests with other phones. Looks like my pbx does exactly what you want (reuse the tcp connection)

BUT

the "contact" header written by Bria incorrectly specifies the wrong TCP port (numerically one below the right one).

Looks like a bug.

You might ask how it ever works (which it must have or you wouldn't have released it). I believe that it would work IF you are behind a NAT and are using stun or ice. That way, the "contact" isn't directly accessed. The pbx would send to an intermediate address that it gets from doing FENT.

Mine is not behind NAT so the alleged bug in Bria comes to the surface.

I think I am not alone because I've seen others with "can't receive calls" problem.

Please let me know if I am on the right track.

[Bogdan]

The connection must be reused even for behind the same NAT case.
This is what we are relying on. Reason:

Apple iOS support for TCP connections applies only for outgoing TCP connections. When in BG, iOS cannot handle incoming TCP connections.

[Bogdan]

Hint: Another common problem is the register expire. The tricky one is the expires imposed by the server side.
BTW: we put "alias" in the Via to give the server another hint to reuse the connection.

[Bogdan]

Another generic comment.
When Apple put TCP Voip support in the iOS, looks like the main driver for them was Skype case (which most likely uses one TCP connection).
Apple does not have deep SIP knowledge too (seems like).

So, in practice SIP TCP to make it work is not an easy task because of some cases missed by Apple / limitations.

[klaidlaw]

Think my last reply got dropped.

Summary:

This is a simple problem of the UA putting the wrong port in the contact header of the REGISTER command.

It is not an iOS problem, not a register timeout problem, not a closed TCP port problem. All those are OK.

This is a simple problem of the UA putting the wrong port in the contact header of the REGISTER command.

See two lines below:

REGISTER sip:laidlaw.private SIP/2.0
Via: SIP/2.0/TCP
192.168.7.131:!!!!!!!!!!!!49487;rport;branch=z9hG4bKPjzZnBwF3yd8fNPtG0QE szLP72vl12faa1;alias

Max-Forwards: 70
From: "Brooke iPod"
< sip:204@laidlaw.private>;tag=D.ujLLC78Fe0FLw3YQKnNf35VKEsVpMi
To: "Brooke iPod" <sip:204@laidlaw.private>
Call-ID: DzvrhVhBFmSZW3I.0RLiy6r8jhtwDSRf
CSeq: 49097 REGISTER
User-Agent: Bria iOS 2.0.0
Contact: "Brooke iPod" <sip:204@192.168.7.131:!!!!!!!!!!!!!!!!!!49486;transport=TCP>
Expires: 600
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Content-Length: 0"


Your example works because your are behind NAT and the NAT fixups mask the problem. I am not behind NAT (couldn't be simpler) so the problem shows up.

This is a simple problem of the UA putting the wrong port in the contact header of the REGISTER command.

I really want to deploy this enterprise wide but can't until this is fixed. Soooo close.

Please advise
Keith

[Bogdan]

I noted before that the connection must be reused (iOS reason), even if u are behind the same NAT.

But let's assume that we change the port in the contact header. To what?
If we use the port of the existing outgoing connection, then "normally" the server would do connect there. So that would not help since the port has outgoing TCP connection/socket bind to it. It will not accept incoming TCP connections on this port.

I'm not aware of a stronger hint to the server (besides the "alias") that will force the server to the reuse. Perhaps presenting in the contact some "invalid/reserverd" port number?

[Bogdan]

Can u try one scenario?

So the understanding is that your server reuses existing connection when it thinks that the client is behind a NAT.
Let's try to make the server thing that u are behind a NAT. Perhaps having STUN ON and Global IP ON will do the trick?