Outbound calls fail

1. Brekeke Product Name and Version: 3.2.3.6/365

2. Java version: 1.6.0_20

3. OS type and the version: Linux 2.6.35-22-server

4. UA (phone), gateway or other hardware/software involved: Cisco VCS

5. Your problem:

When placing calls from a SIP client registered on the Brekeke SIP server to a client registered on a different server (a Cisco VCS), Brekeke seems to ignore the incoming "180 Ringing" and "200 OK" messages, and does not route these to the caller. Instead, it reports a "504 Server Time Out" error as if it never received them.

The servers are on public IPs (on different domains), the clients behind a NAT. When both clients are registered on the Brekeke server, calls work fine. I can not find any other complaints in the log files; the Ringing and OK packets are received, but then just seem to be be ignored.

Thanks.

from captured packets, can you see the 180 or 200 ok routed to any destination by Brekeke SIP Server?

No, I don't see them routed anywhere else. I see an unexpected SRV query for the callee's domain, and that is it.

I now suspect that the problem is related to the contact header in the returned 180 and 200 messages. I get the calls to connect via a couple of SIP servers other than VCS, and I see that in those cases the contact header contains an IP address and the "transport=tcp" parameter, while the VCS returns a FQDN, and does not explicitly specify TCP transport.

nilsed,

Go to the SIP Server's [Block List]->[Blocked IP Address] page.
Can you find the Cisco VCS's IP address there?

If yes, the IP address had been added to the block list.
The SIP Server ignores packets sent from blocked IP addresses.

Let you remove the VCS's IP address from the Block List.
and put its IP in the [Block List]->[Filtering Policy] page with [Action]="Allow".

Also you can tweak blocking thresholds in the [Block List]->[Settings] page.

James, thanks for the suggestion. I checked the blocked IP addresses, and the VCS address is not there. I can even receive an incoming call from that server.

Which transport (UDP, TCP or TLS) are you using between the Brekeke SIP Server and CISCO VCS?

Are "180 Ringing" and "200 OK" sent to the port 5060 ?

The servers communicate using TCP. I see that Brekeke sends the Invite from a dynamically allocated port (56955). The VCS uses this same TCP channel to respond, so the "180 Ringing" and "200 OK" are returned to the sending port number (56955). I was wondering if Brekeke could have a problem parsing the replies from the VCS since the Contact header contains a "gr"-parameter, but I don't see any errors in the log file. The returned contact header looks like this:

Contact: <sip:ep1@ourdomain.com;gr=urn:uuid:7b63a5ed-ee23-5b21-bfdf-fd29fc00ec20>

Set the following line in the [Configuration]->[Advanced] page, and restart the SIP Server.
----------------
net.sip.loglevel.file=255
----------------

After you reproduce the problem, let you check the SIP Server's log.
The log file is stored in <Tomcat's Directory>/webapps/proxy/WEB-INF/work/sv/log/

I checked the log files. While I can see all SIP messages being sent and received correctly, there are no further error messages. The responses are indicated by the lines starting with "tcp-con.2: debug: receive:" but I do not see any corresponding "session.x receive" messages, so I guess Brekeke doesn't recognise that the incoming messages belongs to this session? I repeatedly receive "200 OK" messages from the VCS, and eventually Brekeke reports a "504 server timeout".

Can you paste both INVITE and "180 Ringing" packets here?
You can hide actual IP addresses.

I've pasted the packets below. In summary: there is a NATed Mirial client registered on the Brekeke server (<brekeke ip>, ourdomain.com), calling an endpoint registered on the VCS (<vcs ip>, vcsdomain.com).


tcp-con.5: debug: send: to=<vcs ip>:5060 at 09/18/13 10:08:29.456
==============================================
INVITE sip:c20@vcsdomain.com SIP/2.0
Call-ID: DL5bdb21b6e4-1079447895@Nilsed-PC
To: "sip:c20@vcsdomain.com" <sip:c20@vcsdomain.com>
From: "mirial" <sip:mirial@ourdomain.com>;tag=DLc0e48c8a92;epid=06D14D30
CSeq: 1 INVITE
Max-Forwards: 69
Via: SIP/2.0/TCP <brekeke_ip>:48861;branch=z9hG4bKe047f0ef6c7891ca-30-bf92bd05
Via: SIP/2.0/TCP 192.168.0.135:5060;branch=z9hG4bK-c6f66ed67c-DL;rport=3251;received=<caller ip>
Contact: "mirial" <sip:mirial@<brekeke_ip>:5060;transport=tcp>
Allow: INVITE,CANCEL,ACK,OPTIONS,INFO,SUBSCRIBE,NOTIFY,BYE,MESSAGE,UPDATE,PUBLISH
Accept: application/sdp, application/media_control+xml
User-Agent: LifeSize Softphone 8.1.12 (Windows)
P-Behind-NAT: Yes
Record-Route: <sip:<brekeke_ip>:5060;transport=tcp;lr>
Content-Type: application/sdp
Content-Length: 686

< .... SDP body >

==============================================
tcp-con.5: debug: receive: from=<vcs ip>:5060 at 09/18/13 10:08:29.690
==============================================
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP <brekeke ip>:48861;branch=z9hG4bKe047f0ef6c7891ca-30-bf92bd05;received=<brekeke ip>;ingress-zone=DefaultZone
Via: SIP/2.0/TCP 192.168.0.135:5060;branch=z9hG4bK-c6f66ed67c-DL;rport=3251;received=<caller ip>
Call-ID: DL5bdb21b6e4-1079447895@Nilsed-PC
CSeq: 1 INVITE
From: "mirial" <sip:mirial@ourdomain.com>;tag=DLc0e48c8a92;epid=06D14D30
To: "sip:c20@vcsdomain.com" <sip:c20@vcsdomain.com>;tag=f83d1b25c118ae61
Server: TANDBERG/4120 (X7.2.2)
Content-Length: 0

Do you have the following lines in the [Configuration]->[Advanced] page?
-----------------
net.sip.loglevel.file=255
net.tcp.loglevel.file=255
net.sip.log.keystat = true
-----------------


> I get the calls to connect via a couple of SIP servers other than VCS,

Do you means there are no problem with other SIP servers ?


> I now suspect that the problem is related to the contact header in the returned 180 and 200 messages.

It seems there is no Contact header in the above "180 Ringing" packet image.

I get the call to connect when using sip2sip.info, and I don't actually see that much difference in the responses compared to what I receive from the VCS.

The missing Contact header in the pasted "180 Ringing" response, was caused by me not configuring proxy settings on the callee correctly. I have pasted the "correct" message below. The difference behavior is the same in both cases though.

SIP/2.0 180 Ringing
Via: SIP/2.0/TCP <brekeke_ip>:50190;branch=z9hG4bKd050f1755f893f24-30-f82538a8;received=<brekeke_ip>;ingress-zone=DefaultZone
Via: SIP/2.0/TCP 192.168.0.135:5060;branch=z9hG4bK-6d1608ad54-DL;rport=2207;received=<caller ip>
Call-ID: DLd0e01282c4-1079447895@Nilsed-PC
CSeq: 1 INVITE
Contact: <sip:c20@vcsdomain.com;gr=urn:uuid:7b63a5ed-ee23-5b21-bfdf-fd29fc00ec20>
From: "mirial" <sip:mirial@ourdomain.com>;tag=DLe0f20ac9b6;epid=081A5780
To: "sip:c20@vcsdomain.com" <sip:c20@vcsdomain.com>;tag=5a4698ed9ccfe7a0
Record-Route: <sip:proxy-call-id=0bbb98e4-2101-11e3-aaff-0010f3237752@<vcs ip>:5060;transport=tcp;lr>
Record-Route: <sip:proxy-call-id=0bbb98e4-2101-11e3-aaff-0010f3237752@<vcs ip>:5060;transport=tcp;lr>
Record-Route: <sip:<brekeke_ip>:5060;transport=tcp;lr>
Server: TANDBERG/518 (TC6.1.0.f620458)
Content-Length: 0

I now suspect that the problem may be due to the Via-header in the responses from the VCS.

Looking at the log-files I have notice that when calling the VCS, not even the returned "100 Trying" message seems to be recognised by Brekeke as belonging to the call. By this, I mean that the "tcp-con.x: debug: receive:" section in the log file is not followed by a "session.x: receive:". The topmost Via-header in the response is:

Via: SIP/2.0/TCP <brekeke_ip>:50190;branch=z9hG4bKd050f1755f893f24-30-f82538a8;received=<brekeke_ip>;ingress-zone=DefaultZone

Comparing to a successful call to sip2sip.info, the only difference I can find is that VCS has appended a redundant "received=" parameter, and an "ingress-zone"-parameter.

Is there any "svlistener: KS:" message in the log after "180 Ringing"?

I suppose "received=" and "ingress-zone" parameters don't cause the problem...


Can you connect to the VCS over UDP instead of TCP?
Let you put $transport=udp in the Deploy Pattern.

There is no "svlistener: KS" in the log.

Comparing the log with the call to sip2sip.info (which works), everything looks exactly the same, the only difference I can see is that the VCS has modified the Via-header in the "100 Trying" response (has appended the received and ingress-zone parameters). Does Brekeke expect the returned Via-header to be the same as what it sent out?

Are <brekeke_ip> same in both INVITE and "180 Ringing" ?

Are <brekeke_ip> same in both INVITE and "180 Ringing" ?

Yes, this is the public IP of the Brekeke server, and is the same in the INVITE sent from Brekeke and the "180 Ringing" response received from VCS.