23 Feb
2005
23 Feb
'05
2:17 p.m.
I had this problem just a while ago. It was report to me, from Richard
I think, that somewhere in my ser.cfg an ACK was hitting an
sl_send_reply() which is incorrect.
ACK messages must hit a t_relay() to avoid this message.
Regards,
Paul
On Wed, 23 Feb 2005 11:54:25 +0100, Roel van Dijk <roel(a)almende.com> wrote:
Here's my setup:
NATed UAs -- firewall SER/RTPProxy (bridging mode) -- internet
I'm using a slightly altered version of the 'alg.cfg' that comes with
the nathelper module.
I'm trying to call a UA inside my network from the internet using a
public iptel.org account. Here's the trace of the SIP messages:
UA1 firewall iptel
| | <--INVITE-- |
| | --trying--> |
| <--INVITE-- | |
| --trying--> | |
| --ringing--> | |
| --OK--> | |
| | --OK--> |
| | <--ACK-- |
| ACK |
| ACK |
| ACK |
| | |
If we look at the ACK that comes back from Iptel, we see that the IP
address of UA1 is missing, and therefore the routing fails, and never
leaves the SER on the firewall (obscured IP addresses, but given a
name):
U IPTEL.IP.ADDRESS:5060 -> FIREWALL.PUBLIC.IP.ADDRESS:5060
ACK sip:126@FIREWALL.PUBLIC.IP.ADDRESS:5060 SIP/2.0..Record-Route:
<sip:IPTEL.IP.ADDRESS;ftag=2664746953;lr=on>..Content-Length:
0..Contact: <sip:rdvdijk@HOME.PUBLIC.IP.ADDRESS:5060;nat=yes>..Call-ID:
C8E48A38-6C23-42AB-9EF1-6213B2DF4CD0@192.168.0.2..Max-Forwards:
16..CSeq: 2 ACK..From:<sip:rdvdijk@iptel.org>;tag=2664746953..Route:
<sip:FIREWALL.PUBLIC.IP.ADDRESS;ftag=2664746953;lr=on>..To:
<sip:126@my.realm>;tag=947fb3ad8fdd13a6..User-Agent:
SJLabs-SJphone/1.30.235d..Via: SIP/2.0/UDP
IPTEL.IP.ADDRESS;branch=0..Via: SIP/2.0/UDP
192.168.0.2:5060;rport=5060;received=HOME.PUBLIC.IP.ADDRESS;branch=z9hG4
bKc0a800020131c9b1421c4c560000318a000000bc..P-hint:
rr-enforced..P-NATed-URI: YES..P-RTP-Proxy: NO..P-Marked-Contact:
YES..P-Behind-NAT: Yes....
As we see, the UA1's local IP address is nowhere to be found in the ACK
coming back from Iptel. The other local IP address from my the
iptel-account can be found (192.168.0.2). What we do see is: Route:
<sip:FIREWALL.PUBLIC.IP.ADDRESS;ftag=2664746953;lr=on>, and the ACK is
routed back to the SER a few times until I get this message in my logs:
Warning: sl_send_reply: I won't send a reply for ACK!!
When I hang up both sides, I see the same behaviour for the BYE message,
which is routed back to the SER itself as well.
So, what is my problem?
Roel van Dijk
PS config files can be supplied if needed, but it looks very much like
the original alg.cfg, no serious changes as far as I can see.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers