[OpenSIPS-Users] tcp io logs, loop

2016-11-02 Thread Dawid Mielnik 
Hi,

I have a reduntant OpenSIPS 2.2.1 setup with clusterer and binary interface
replication. TCP is not used for SIP. A few times I have observed debug log
being flooded with messages like these below.
What is causing them ? Should I be worried ? How to get rid of this issue ?

Oct 17 11:25:56.281436 DEB 4315  DBG:maxfwd:is_maxfwd_present: value = 70
Oct 17 11:25:56.281481 DEB 4315  DBG:uri:has_totag: no totag
Oct 17 11:25:56.281492 DEB 4315  DBG:siptrace:sip_trace_w: can't trace
dialog! Will try to trace transaction
Oct 17 11:25:56.281498 DEB 4315  DBG:siptrace:sip_trace_w: tracing
transaction!
Oct 17 11:25:56.281502 DEB 4315  DBG:core:parse_to_param: tag=as09518802
Oct 17 11:25:56.281507 DEB 4315  DBG:core:parse_to: end of header reached,
state=29
Oct 17 11:25:56.281511 DEB 4315  DBG:core:parse_to: display={"asterisk"},
ruri={sip:aster...@xx.xx.xxx.253}
Oct 17 11:25:56.281516 DEB 4315  DBG:core:parse_headers: flags=40
Oct 17 11:25:56.281521 DEB 4315  DBG:siptrace:sip_trace: sip_trace called
Oct 17 11:25:56.281525 DEB 4315  DBG:siptrace:pipport2su: proto 17, host
XX.XX.XXX.253 , port 5060
Oct 17 11:25:56.281530 DEB 4315  DBG:siptrace:pipport2su: proto 17, host
XX.XX.XXX.250 , port 5060
Oct 17 11:25:56.281535 DEB 4315  DBG:core:mk_proxy: doing DNS lookup...
Oct 17 11:25:56.281539 DEB 4315  DBG:core:comp_scriptvar: int 20 : 5060 /
5060
Oct 17 11:25:56.281543 DEB 4315  DBG:core:parse_headers:
flags=
Oct 17 11:25:56.281548 DEB 4315  DBG:core:check_ip_address: params
XX.XX.XXX.253, XX.XX.XXX.253, 0
Oct 17 11:25:56.281552 DEB 4315  DBG:core:parse_headers: flags=40
Oct 17 11:25:56.281570 DEB 4315  DBG:siptrace:pipport2su: proto 17, host
XX.XX.XXX.250 , port 5060
Oct 17 11:25:56.281576 DEB 4315  DBG:siptrace:pipport2su: proto 17, host
XX.XX.XXX.253 , port 5060
Oct 17 11:25:56.281581 DEB 4315  DBG:core:mk_proxy: doing DNS lookup...
Oct 17 11:25:56.281664 DEB 4315  DBG:core:destroy_avp_list: destroying list
(nil)
Oct 17 11:25:56.281673 DEB 4315  DBG:core:receive_msg: cleaning up
Oct 17 11:25:58.515305 DEB 4335  DBG:core:handle_tcpconn_ev: data available
on 0x7f2da0d453c8 48
Oct 17 11:25:58.515378 DEB 4335  DBG:core:io_watch_del: [TCP_main]
io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called
Oct 17 11:25:58.515387 DEB 4335  DBG:core:send2child: to tcp child 0
0(4327), 0x7f2da0d453c8 rw 1
Oct 17 11:25:58.515792 DEB 4327  DBG:core:handle_io: We have received conn
0x7f2da0d453c8 with rw 1 on fd 8
Oct 17 11:25:58.515814 DEB 4327  DBG:core:io_watch_add: [TCP_worker]
io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024
Oct 17 11:25:58.515820 DEB 4327  DBG:core:tcp_receive_timeout:
0x7f2da0d453c8 expired - (221, 222) lt=221
Oct 17 11:25:58.515825 DEB 4327  DBG:core:io_watch_del: [TCP_worker]
io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called
Oct 17 11:25:58.515830 DEB 4327  DBG:core:tcpconn_release:  releasing con
0x7f2da0d453c8, state 0, fd=-1, id=1
Oct 17 11:25:58.515835 DEB 4327  DBG:core:tcpconn_release:  extra_data (nil)
Oct 17 11:25:58.515840 DEB 4335  DBG:core:handle_tcp_worker: reader
response= 7f2da0d453c8, 0 from 0
Oct 17 11:25:58.515844 DEB 4335  DBG:core:io_watch_add: [TCP_main]
io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1),
fd_no=35/1024
Oct 17 11:25:58.515856 DEB 4335  DBG:core:handle_tcpconn_ev: data available
on 0x7f2da0d453c8 48
Oct 17 11:25:58.515861 DEB 4335  DBG:core:io_watch_del: [TCP_main]
io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called
Oct 17 11:25:58.516050 DEB 4335  DBG:core:send2child: to tcp child 0
0(4327), 0x7f2da0d453c8 rw 1
Oct 17 11:25:58.516163 DEB 4327  DBG:core:handle_io: We have received conn
0x7f2da0d453c8 with rw 1 on fd 8
Oct 17 11:25:58.516187 DEB 4327  DBG:core:io_watch_add: [TCP_worker]
io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024
Oct 17 11:25:58.516193 DEB 4327  DBG:core:tcp_receive_timeout:
0x7f2da0d453c8 expired - (221, 222) lt=221
Oct 17 11:25:58.516198 DEB 4327  DBG:core:io_watch_del: [TCP_worker]
io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called
Oct 17 11:25:58.516203 DEB 4327  DBG:core:tcpconn_release:  releasing con
0x7f2da0d453c8, state 0, fd=-1, id=1
Oct 17 11:25:58.516208 DEB 4327  DBG:core:tcpconn_release:  extra_data (nil)
Oct 17 11:25:58.516332 DEB 4335  DBG:core:handle_tcp_worker: reader
response= 7f2da0d453c8, 0 from 0
Oct 17 11:25:58.516343 DEB 4335  DBG:core:io_watch_add: [TCP_main]
io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1),
fd_no=35/1024
Oct 17 11:25:58.516349 DEB 4335  DBG:core:handle_tcpconn_ev: data available
on 0x7f2da0d453c8 48
Oct 17 11:25:58.516353 DEB 4335  DBG:core:io_watch_del: [TCP_main]
io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called
Oct 17 11:25:58.516358 DEB 4335  DBG:core:send2child: to tcp child 0
0(4327), 0x7f2da0d453c8 rw 1
Oct 17 11:25:58.516431 DEB 4327  DBG:core:handle_io: We have received conn
0x7f2da0d453c8 with rw 1 on

Re: [OpenSIPS-Users] opensips 2.1 call_center queue position (Jonathan Hunter)

2016-11-02 Thread koce 
Hello I recently started to explore call_center module and I think that 
it might not be patch related.


here is my experience.

I downloaded opensips branch 2.2 commit c8a605b.

when agent is registered and there are no clients in line/queue the 
caller gets connected to the agent


almost instantly and everything works fine.

If the agent is in wrapup_time and I call again the same flow/queue 
I get send to the media server and moh starts streaming. Now when the 
wrapup_time finishes and the caller needs to be connected to the agent 
or somewhere earlier before that opensips crashes and caller is stuck in 
moh stream. but if there is no call during wrapup_time period and I call 
again everything works fine.


tested with 1 agent in 2 flows, 1 user and asterisk as media server to 
stream moh
sorry if I high jacket this thread but I think it's relevant to the 
crash Jonathan Hunter is experiencing.

==
last few log lines from the crash
Nov  2 08:01:12 opensips /sbin/opensips[12152]: b2b_reply BYE : 
[F=sip:use...@opensips.test R= D=UA= 
IP=(192.168.116.125:5060 192.168.116.125:5060) 
ID=B2B.323.7879765.1478070026]
Nov  2 08:01:20 opensips /sbin/opensips[12151]: CALLCENTER MODULE: 
[F=sip:use...@opensips.test R=sip:engl...@opensips.test D= 
M=INVITE IP=(192.168.69.114:39336 192.168.116.125:5060) 
ID=zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q]
Nov  2 08:01:20 opensips /sbin/opensips[12151]: 
INFO:b2b_logic:b2bl_add_client: adding entity 
[0xb33c9c4c]->[B2B.464.2920496.1478070079] to tuple [0xb33c9d40]->[13.0]
Nov  2 08:01:20 opensips /sbin/opensips[12152]: 
INFO:b2b_logic:b2b_add_dlginfo: Dialog pair: 
[zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q] - [B2B.464.2920496.1478070079]
Nov  2 08:01:20 opensips /sbin/opensips[12152]: b2b_reply INVITE : 
[F=sip:use...@opensips.test R= D= UA= 
IP=(192.168.117.100:5065 192.168.116.125:5060) 
ID=B2B.464.2920496.1478070079]
Nov  2 08:01:21 opensips /sbin/opensips[12152]: b2b_request ACK : 
[F=sip:use...@opensips.test R=sip:192.168.116.125:5060 D= 
UA= IP=(192.168.69.114:39336 192.168.116.125:5060) 
ID=zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q]
Nov  2 08:01:25 opensips /sbin/opensips[12152]: b2b_request INVITE : 
[F=sip:use...@opensips.test R=sip:192.168.116.125:5060 D= 
UA= IP=(192.168.69.114:39336 192.168.116.125:5060) 
ID=zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q]
Nov  2 08:01:26 opensips /sbin/opensips[12124]: INFO:core:handle_sigs: 
child process 12152 exited by a signal 11
Nov  2 08:01:26 opensips /sbin/opensips[12181]: 
CRITICAL:core:receive_fd: EOF on 34
Nov  2 08:01:26 opensips /sbin/opensips[12124]: INFO:core:handle_sigs: 
core was generated
Nov  2 08:01:26 opensips /sbin/opensips[12124]: INFO:core:handle_sigs: 
terminating due to SIGCHLD
Nov  2 08:01:26 opensips /sbin/opensips[12181]: INFO:core:sig_usr: 
signal 15 received
Nov  2 08:01:26 opensips /sbin/opensips[12173]: INFO:core:sig_usr: 
signal 15 received




On 11/02/2016 10:33 AM, users-requ...@lists.opensips.org wrote:

Re: opensips 2.1 call_center queue position (Jonathan Hunter)



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Routing in opensips

2016-11-02 Thread Eric Freeman 
Thank you. I will test with that IP. How do I change the SDP to my public IP 
address so I can get RTP information back?


Thank you,


Eric Freeman

Technical Director/NA for TBWA\Chiat\Day

TBWA\Chiat\Day New York
488 Madison Ave.
New York NY 10022
United States of America
Tel: +12128041324


From: Bogdan-Andrei Iancu 
Sent: Tuesday, November 1, 2016 7:10:45 AM
To: Eric Freeman; users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Routing in opensips

Hi Eric,

The outgoing INVITE request looks ok - the RR and VIA headers carry the public 
IP of your OpenSIPS. You should get back some reply. Not sure how valid is that 
test server, but you can try sending to sip:opensips.org:5060 ( or 
78.46.64.50:5060 ) - this sip server is definitely up .

BTW, the SDP you send out is bogus as it contain only private IPs, so the other 
end point will not be able to send you ant RTP back.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 31.10.2016 14:21, Eric Freeman wrote:

Please attached pcap file. Is this what you need?


Eric Freeman

Technical Director/NA for TBWA\Chiat\Day

TBWA\Chiat\Day New York
488 Madison Ave.
New York NY 10022
United States of America
Tel: +12128041324

From: Bogdan-Andrei Iancu 
Sent: Monday, October 31, 2016 6:36:18 AM
To: Eric Freeman; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Routing in opensips

Hi Eric,

What I'm asking here is to post the full INVITE packet from your opensips 
server to the external host - I Want to to check the SIP headers and the SDP.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 25.10.2016 16:38, Eric Freeman wrote:

The opensips server is 10.88.23.13 the video conference server is 10.89.71.12. 
The IP I am trying to connect to 199.48.152.152, I believe is a valid host. I 
found it on a test SIP site on the Internet


10:02:59.346842 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: INVITE 
sip:111@199.48.152.152 SIP/2.0

10:02:59.351769 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 100 Giving a 
try

10:02:59.352232 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: 
INVITE sip:111@199.48.152.152 SIP/2.0

10:02:59.352238 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:02:59.871480 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: 
INVITE sip:111@199.48.152.152 SIP/2.0

10:02:59.871489 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:03:00.874461 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: 
INVITE sip:111@199.48.152.152 SIP/2.0

10:03:00.874483 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:03:02.877430 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: 
INVITE sip:111@199.48.152.152 SIP/2.0

10:03:02.877440 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:03:03.930697 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 408 Request 
Timeout

10:03:03.958682 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: ACK 
sip:111@199.48.152.152 SIP/2.0


Eric Freeman

Technical Director/NA for TBWA\Chiat\Day

TBWA\Chiat\Day New York
488 Madison Ave.
New York NY 10022
United States of America
Tel: +12128041324

From: Bogdan-Andrei Iancu 
Sent: Tuesday, October 25, 2016 7:04:15 AM
To: Eric Freeman; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Routing in opensips

Hi Eric,

By traffic (coming back), you understand RTP or SIP traffic ?

Could you post the INVITE message getting out of your server ? I suspect the 
INVITE has in SDP a private IP that is not reachable for the end device (where 
the call is sent).

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 21.10.2016 18:46, Eric Freeman wrote:

Yes, I see Request INVITE going to the device I am calling. I do not see any 
traffic coming back. I am following up with my Firewall team.

My Firewall team suggested I might need to change the RTP ports to use UDP 
2326-2485. Where do I change/check these settings on the OpenSIPs server to see 
if I have the traffic going out those ports.


Thanks,


Eric Freeman

Technical Director/NA for TBWA\Chiat\Day

TBWA\Chiat\Day New York
488 Madison Ave.
New York NY 10022
United States of America
Tel: +12128041324

From: Bogdan-Andrei Iancu 
Sent: Monday, October 3, 2016 4:44:26 AM
To: Eric Freeman; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Routing in opensips

Hi

Re: [OpenSIPS-Users] Routing in opensips

2016-11-02 Thread Bogdan-Andrei Iancu 

Eric,

You can simply change it with the fix_nated_sdp() function:
http://www.opensips.org/html/docs/modules/2.2.x/nathelper.html#id294042

But you have to be careful that the IP:port you force in SDP is also 
valid from IP perspective - like any RTP traffic landing on that IP is 
actually getting to the right application.


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 01.11.2016 14:24, Eric Freeman wrote:


Thank you. I will test with that IP. How do I change the SDP to my 
public IP address so I can get RTP information back?



Thank you,


Eric Freeman

Technical Director/NA for TBWA\Chiat\Day

TBWA\Chiat\Day New York
488 Madison Ave.
New York NY 10022
United States of America
Tel: +12128041324 

*From:* Bogdan-Andrei Iancu 
*Sent:* Tuesday, November 1, 2016 7:10:45 AM
*To:* Eric Freeman; users@lists.opensips.org
*Subject:* Re: [OpenSIPS-Users] Routing in opensips
Hi Eric,

The outgoing INVITE request looks ok - the RR and VIA headers carry 
the public IP of your OpenSIPS. You should get back some reply. Not 
sure how valid is that test server, but you can try sending to 
sip:opensips.org:5060 ( or 78.46.64.50:5060 ) - this sip server is 
definitely up .


BTW, the SDP you send out is bogus as it contain only private IPs, so 
the other end point will not be able to send you ant RTP back.


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 31.10.2016 14:21, Eric Freeman wrote:


Please attached pcap file. Is this what you need?


Eric Freeman

Technical Director/NA for TBWA\Chiat\Day

TBWA\Chiat\Day New York
488 Madison Ave.
New York NY 10022
United States of America
Tel: +12128041324 

*From:* Bogdan-Andrei Iancu 
*Sent:* Monday, October 31, 2016 6:36:18 AM
*To:* Eric Freeman; OpenSIPS users mailling list
*Subject:* Re: [OpenSIPS-Users] Routing in opensips
Hi Eric,

What I'm asking here is to post the full INVITE packet from your 
opensips server to the external host - I Want to to check the SIP 
headers and the SDP.


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 25.10.2016 16:38, Eric Freeman wrote:


The opensips server is 10.88.23.13 the video conference server is 
10.89.71.12. The IP I am trying to connect to 199.48.152.152, I 
believe is a valid host. I found it on a test SIP site on the Internet



10:02:59.346842 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: INVITE 
sip:111@199.48.152.152 SIP/2.0


10:02:59.351769 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 
100 Giving a try


10:02:59.352232 IP 10.88.23.13.sip > 
sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE 
sip:111@199.48.152.152 SIP/2.0


10:02:59.352238 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:02:59.871480 IP 10.88.23.13.sip > 
sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE 
sip:111@199.48.152.152 SIP/2.0


10:02:59.871489 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:03:00.874461 IP 10.88.23.13.sip > 
sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE 
sip:111@199.48.152.152 SIP/2.0


10:03:00.874483 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:03:02.877430 IP 10.88.23.13.sip > 
sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE 
sip:111@199.48.152.152 SIP/2.0


10:03:02.877440 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:03:03.930697 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 
408 Request Timeout


10:03:03.958682 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: ACK 
sip:111@199.48.152.152 SIP/2.0



Eric Freeman

Technical Director/NA for TBWA\Chiat\Day

TBWA\Chiat\Day New York
488 Madison Ave.
New York NY 10022
United States of America
Tel: +12128041324 

*From:* Bogdan-Andrei Iancu 
*Sent:* Tuesday, October 25, 2016 7:04:15 AM
*To:* Eric Freeman; OpenSIPS users mailling list
*Subject:* Re: [OpenSIPS-Users] Routing in opensips
Hi Eric,

By traffic (coming back), you understand RTP or SIP traffic ?

Could you post the INVITE message getting out of your server ? I 
suspect the INVITE has in SDP a private IP that is not reachable for 
the end device (where the call is sent).


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 21.10.2016 18:46, Eric Freeman wrote:


Yes, I see Request INVITE going to the device I am calling. I do 
not see any traffic coming back. I am following up with my Firewall 
team.


My Firewall team suggested I might need to change the RTP ports to 
use UDP 2326-2485. Where do I change/check these settings on the 
OpenSIPs server to see if I have the traffic going out those ports.



Thanks,


Eric Freeman

Technical Director/NA for

Re: [OpenSIPS-Users] multiple retransmissions on 4XX after ACK [Solved]

2016-11-02 Thread Richard Robson 

  
  
Hi,
  
  I had 
   if (!topology_hiding_match() )
  
  this used to exit the script, but  now handles the ack and relays
  it.
  
  there was a handler for the ack but the script had exited before
  it got there.
  
  it was then a case of handleing the ACK in the topology map check
  or in the script and so chose the former option.
  
  Its all working now.
  
  R
  
  On 18/10/2016 15:22, Newlin, Ben wrote:


  
  
  
  
  
  
So you are
saying the issue has been resolved by performing matching on
the ACK?
 
If not, I would
still need a full transaction trace. Many components of the
ACK for a failure response are dependent on fields in the
initial INVITE, which was not included.
 

  
 
  

Ben
Newlin
 

  From: 

  on behalf of Richard Robson
  
  Organization: Greenlight Innovation
  Reply-To: OpenSIPS users mailling list
  
  Date: Wednesday, October 12, 2016 at 8:08 AM
  To: "users@lists.opensips.org"
  
  Subject: Re: [OpenSIPS-Users] multiple
  retransmissions on 4XX after ACK [Solved]


   


  OK, I am using topolgy hiding and
checking for this but the ACK wasn't being handled in the
topology_hiding_match

On 11/10/2016 14:04, Richard Robson wrote:


  
Does this help?
  
  4XX
  
  2016/10/11 14:02:44.810905 192.168.36.141:5060 ->
  192.168.36.68:5060
  SIP/2.0 487 Request Terminated
  Via: SIP/2.0/UDP
192.168.36.68:5060;received=192.168.36.68;rport=5060;branch=z9hG4bK789668db
  From: ;tag=as04ad0c35
  To: ;tag=as3154cbe9
  Call-ID: 7f643eb34e5355e54575f8ec391740d3@192.168.36.68:5060
  CSeq: 103 INVITE
  Server: FPBX-12.0.76.4(11.5.1)
  Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
  SUBSCRIBE, NOTIFY, INFO, PUBLISH
  Supported: replaces, timer
  Content-Length: 0
  
  
  ACK
  
  2016/10/11 14:02:44.811879 192.168.36.68:5060 ->
  192.168.36.141:5060
  ACK sip:441382250630@141.170.9.156:5060;did=a8f.46c3a1f1
  SIP/2.0
  Via: SIP/2.0/UDP
  192.168.36.68:5060;branch=z9hG4bK789668db;rport
  Max-Forwards: 70
  From: ;tag=as04ad0c35
  To: ;tag=as3154cbe9
  Contact: 
  Call-ID: 7f643eb34e5355e54575f8ec391740d3@192.168.36.68:5060
  CSeq: 103 ACK
  User-Agent: FPBX-12.0.76.4(11.5.1)
  Content-Length: 0
  
  
  Regards,
  
  Richard
  
  
  On 10/10/2016 17:52, Newlin, Ben wrote:
  
  
It’s
impossible to say whether the ACK or the 4XX response
are formatted properly from just seeing the ACK. The
entire transaction is necessary.
 

  
 
  

Ben
Newlin
 

  From: 

  on behalf of Richard Robson
  
  Organization: Greenlight Innovation
  Reply-To: OpenSIPS users mailling list 

  Date: Monday, October 10, 2016 at 12:33 PM
  To: OpenSIPS users mailling list 

  Subject: Re: [OpenSIPS-Users] multiple
  retransmissions on 4XX after ACK


   


  Hi All

I've made tha call from an internal machine and opensips
still appears to ignore the ACKs

The ACK looks to be OK

2016/10/10 17:28:20.183387 192.168.36.92:5060 ->
192.168.36.141:5060
ACK sip:01382250631@192.168.36.141