I would say that for some reason your ser.cfg manipulated the ruri into SER's IP address. AFAIK, t_relay() will always send to the current ruri (and branches). BTW, do you have 10.3.0.221 as an alias? g-)
Java Rockx wrote:
Hi All.
If I have the following INVITE message, the message is sent to 10.3.0.221:5060.
How does t_relay() determine this? Is it because that is the IP in the R-URI?
I have a very odd situation where the INVITE is sent to an IP that is the same as the SER proxy, but the R-URI is a SIP phone on the public internet.
This causes SER to send the message to iteself, which then causes (uri==myself) to be FALSE and I just t_relay() it again in my default handling.
Does anyone know why ser might attempt to send a message to an IP that is __not__ the R-URI? In this example I do have "sip.mycompany.com" defined as an alias so I'm not sure what could be causing this loop.
U 2005/04/01 11:15:09.620910 66.90.46.29:33697 -> 10.3.0.221:5060 INVITE sip:3212514239@sip.mycompany.com;user=phone SIP/2.0. Via: SIP/2.0/UDP 172.31.130.83:33697;branch=z9hG4bK02b13d3f9557e284.
U 2005/04/01 11:15:09.633247 10.3.0.221:5060 -> 66.90.46.29:33697 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 172.31.130.83:33697;branch=z9hG4bK02b13d3f9557e284;rport=33697;received=66.90.46.29.
U 2005/04/01 11:15:09.633687 10.3.0.221:5060 -> 10.3.0.221:5060 INVITE sip:3212514239@172.31.130.110;user=phone SIP/2.0. Record-Route: sip:3212514239@10.3.0.221:5060;nat=yes;ftag=946f5da2c0d8a21c;lr. Via: SIP/2.0/UDP 10.3.0.221;branch=z9hG4bK8ca2.b43bda21.0. Via: SIP/2.0/UDP 172.31.130.83:33697;rport=33697;received=66.90.46.29;branch=z9hG4bK02b13d3f9557e284.
Regards, Paul
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers