I'm testing SIP trunking connectivity to an ITSP through a Covergence (CXC)/ACME Packet session border controller. Calls from an IP phone to the PSTN through SER and the CXC are being dropped 15 seconds after the initial call is setup and just after a cal l is answered. We do not have this problem with calls which reach the PSTN via local gateways. It seems that SER is not relaying an ACK which it receives from the phone which causes the SBC to resend a 200 OK message until finally the connection times out. I've checked the call routing and do not see any issue however I do notice the following in the SER logs.
Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: --ACK--: Time: [Thu Aug 13 13:07:24 2009] From: sip:89390@vidar.net.isc.upenn.edu To sip:92155738396@vidar.net.isc.upenn.edu;user=phone Src IP <128.91.2.223> Method:<ACK> Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: [Thu Aug 13 13:07:24 2009] [453a4bbf-90848c86-ea3a8091@128.91.56.18] sip:92155738396@vidar.net.isc.upenn.edu:5060;user=phone;maddr=128.91.56.242;transport=udp Starting PRESENCE/BLA section Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: [Thu Aug 13 13:07:24 2009] [453a4bbf-90848c86-ea3a8091@128.91.56.18] sip:92155738396@vidar.net.isc.upenn.edu:5060;user=phone;maddr=128.91.56.242;transport=udp End PRESENCE/BLA section Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: [Thu Aug 13 13:07:24 2009] [453a4bbf-90848c86-ea3a8091@128.91.56.18] --URI match--. Method: <ACK> R-uri: sip:92155738396@vidar.net.isc.upenn.edu:5060;user=phone;maddr=128.91.56.242;transport=udp Contact Header: <sip:89390@128.91.56.18:5060> From: sip:89390@vidar.net.isc.upenn.edu To sip:92155738396@vidar.net.isc.upenn.edu;user=phone IP source address <128.91.2.223> Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: --ACK--: Time: [Thu Aug 13 13:07:24 2009] From: sip:89390@vidar.net.isc.upenn.edu To sip:92155738396@vidar.net.isc.upenn.edu;user=phone Src IP <128.91.2.223> Method:<ACK> Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: Too many hops Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: Warning: sl_send_reply: I won't send a reply for ACK!!
User 89390 is a local subscriber and the phone initiating the call. The recipient of the call is my desk phone 215-573-8396 which is on a different, unrelated SER service.
We do record_route traffic through SER for call control and accounting reasons. It seems like the ACK is looping through SER and therefore never being sent to the SBC but I cannot see why. Does anyone have any thoughts on this issue?
Thanks,Steve
Steven C. Blair píše v Pá 14. 08. 2009 v 09:30 -0400:
Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: --ACK--: Time: [Thu Aug 13 13:07:24 2009] From: sip:89390@vidar.net.isc.upenn.edu To sip:92155738396@vidar.net.isc.upenn.edu;user=phone Src IP <128.91.2.223> Method:<ACK>
OK, ACK is received by SER... but is routed incorrectly to itself...
Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: Too many hops
(qualified guess... to proove it sniff traffic on loopback interface) ... so it ends it the loop, cut off by Max-Forwards limit...
Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: Warning: sl_send_reply: I won't send a reply for ACK!!
... it tries to reply 4xx Too many hops, by it's not possible for ACK.
Resume: check your SER script, how you route the 2xx ACK.
Michal
Michal,
In route block 0 I use the following logic for relaying messages.
# Call Tear-Down Section for ACKs - do not account for acks if (method=="ACK") { xlog("L_INFO", "\n[SER]: --ACK--: Time: [%Tf] From: <%fu> To <%tu> Src IP <%is> Method:<%rm>\n"); t_relay(); break; };
-Steve
-----Original Message----- From: Michal Matyska [mailto:michal.matyska@iptel.org] Sent: Friday, August 14, 2009 10:28 AM To: Steven C. Blair Cc: serusers@lists.iptel.org Subject: Re: [Serusers] 200 OK not being ACKnowledged
Steven C. Blair píše v Pá 14. 08. 2009 v 09:30 -0400:
Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: --ACK--: Time: [Thu Aug 13 13:07:24 2009] From: sip:89390@vidar.net.isc.upenn.edu To sip:92155738396@vidar.net.isc.upenn.edu;user=phone Src IP <128.91.2.223> Method:<ACK>
OK, ACK is received by SER... but is routed incorrectly to itself...
Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: Too many hops
(qualified guess... to proove it sniff traffic on loopback interface) ... so it ends it the loop, cut off by Max-Forwards limit...
Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: Warning: sl_send_reply: I won't send a reply for ACK!!
... it tries to reply 4xx Too many hops, by it's not possible for ACK.
Resume: check your SER script, how you route the 2xx ACK.
Michal
Steven C. Blair wrote:
In route block 0 I use the following logic for relaying messages.
# Call Tear-Down Section for ACKs - do not account for acks if (method=="ACK") { xlog("L_INFO", "\n[SER]: --ACK--: Time: [%Tf] From: <%fu> To <%tu> Src IP <%is> Method:<%rm>\n"); t_relay(); break; };
These ACKs are record routed messages like the BYE and thus should be forwarded using something like this:
if (loose_route()) { t_relay(); break }
loose_route() does all the necessary magic to find out the next hop. You should have a block like that already somewhere. Just removing the ACK block should do the trick.
Regards, Martin
-----Original Message----- From: Martin Hoffmann [mailto:hn@nvnc.de] Sent: Friday, August 14, 2009 11:55 AM To: Steven C. Blair Cc: Michal Matyska; serusers@lists.iptel.org Subject: Re: [Serusers] 200 OK not being ACKnowledged
Steven C. Blair wrote:
In route block 0 I use the following logic for relaying messages.
# Call Tear-Down Section for ACKs - do not account for acks if (method=="ACK") { xlog("L_INFO", "\n[SER]: --ACK--: Time: [%Tf] From: <%fu> To <%tu> Src IP <%is> Method:<%rm>\n"); t_relay(); break; };
These ACKs are record routed messages like the BYE and thus should be forwarded using something like this:
if (loose_route()) { t_relay(); break }
loose_route() does all the necessary magic to find out the next hop. You should have a block like that already somewhere. Just removing the ACK block should do the trick.
I do but that was not enough. Apparently the CXC was attempting to forward based on the maddr value while SER was using to/from/via headers. Changing the CXC to ignore the maddr header fixed the problem
-Steve
Regards, Martin
The problem was a configuration issue with the CXC. It has been resolved by the vendor and calls are being processed correctly.
Thanks for the help, Steve
-----Original Message----- From: Michal Matyska [mailto:michal.matyska@iptel.org] Sent: Friday, August 14, 2009 10:28 AM To: Steven C. Blair Cc: serusers@lists.iptel.org Subject: Re: [Serusers] 200 OK not being ACKnowledged
Steven C. Blair píše v Pá 14. 08. 2009 v 09:30 -0400:
Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: --ACK--: Time: [Thu Aug 13 13:07:24 2009] From: sip:89390@vidar.net.isc.upenn.edu To sip:92155738396@vidar.net.isc.upenn.edu;user=phone Src IP <128.91.2.223> Method:<ACK>
OK, ACK is received by SER... but is routed incorrectly to itself...
Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: Too many hops
(qualified guess... to proove it sniff traffic on loopback interface) ... so it ends it the loop, cut off by Max-Forwards limit...
Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: Warning: sl_send_reply: I won't send a reply for ACK!!
... it tries to reply 4xx Too many hops, by it's not possible for ACK.
Resume: check your SER script, how you route the 2xx ACK.
Michal
-
Martin Hoffmann -
Michal Matyska -
Steven C. Blair