14 Aug
2009
14 Aug
'09
3:30 p.m.
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(a)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(a)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(a)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
14 Aug
14 Aug
4:27 p.m.
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
4:36 p.m.
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(a)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
5:55 p.m.
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
7:08 p.m.
-----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(a)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
4:43 p.m.
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(a)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
5376
days inactive
5376
days old
5 comments
3 participants
participants (3)
-
Martin Hoffmann -
Michal Matyska -
Steven C. Blair