Hello,
I'm need some help with SIP protocol / SER configuration to resolve a problem.
I have a system with a SER instance and a SIP client application running on the same box.
SER is 10.50.32.10:5060 APP is 10.50.32.10:5070 Remote SIP server 10.1.39.10 Remote phone is 10.1.39.202
The user agent is registered with the SER instance as extension 1009. It has aliases 1001-1008 and is actually called as 231x which maps onto 100x which then connects to extension 1009.
The remote phone makes a call to the user agent application via the remote SIP server and the SER instance. It dials 2311 which gets automagically converted to extension 1009
The call is established but the user application times out and detects a disconnect despite the calling phone not hanging up. In my wireshark trace it seems that SER is ignoring some form of keep-alive from the remote SIP server and this is causing the timeout. The lines of interest include 39, 42, 45, 50, 53, 56, 59
Lines 28 and others similar are on the loopback interface and are packets between port 5060 and 5070
Can someone please advise if the SIP protocol has problems and/or if SER configuration has problems?
22 0.218826 10.50.32.10 -> 127.0.0.1 SIP Request: REGISTER sip:localhost.localdomain 23 0.219570 127.0.0.1 -> 10.50.32.10 SIP Status: 200 OK (1 bindings) 24 19.472555 10.1.39.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1001@butler.fesa.sto;transport=udp, with session description 25 19.473394 10.50.32.10 -> 10.1.39.10 SIP Status: 100 trying -- your call is important to us 26 19.473596 10.50.32.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1009@10.50.32.10:5070;LINEID=1d5a67e38809, with session description 27 19.484244 10.50.32.10 -> 10.50.32.10 SIP Status: 100 Trying 28 19.725476 10.50.32.10 -> 10.50.32.10 SIP Status: 180 Ringing 29 19.725828 10.50.32.10 -> 10.1.39.10 SIP Status: 180 Ringing 32 21.770798 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 33 21.782437 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 38 21.789396 10.50.32.10 -> 10.1.39.202 RTCP Source port: 8001 Destination port: 16391 39 21.800069 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 40 22.278096 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 41 22.278713 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 42 22.298101 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 43 23.285536 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 44 23.288988 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 45 23.307839 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 48 25.298214 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 49 25.299105 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 50 25.317892 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 51 29.306496 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 52 29.306758 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 53 29.328420 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 54 33.314736 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 55 33.318736 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 56 33.338302 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 57 37.323175 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 58 37.324791 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 59 37.347936 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809
--> client detects disconnect here
Thanks
jeremy
I'm on my mobile, so this is a quick suggestion: verify that your app receives the ACK. It seems to me that 200 Ok is resent. g-)
------- Original message ------- From: Jeremy A jeremy@electrosilk.net Sent: 28.11.'07, 4:22
Hello,
I'm need some help with SIP protocol / SER configuration to resolve a problem.
I have a system with a SER instance and a SIP client application running on the same box.
SER is 10.50.32.10:5060 APP is 10.50.32.10:5070 Remote SIP server 10.1.39.10 Remote phone is 10.1.39.202
The user agent is registered with the SER instance as extension 1009. It has aliases 1001-1008 and is actually called as 231x which maps onto 100x which then connects to extension 1009.
The remote phone makes a call to the user agent application via the remote SIP server and the SER instance. It dials 2311 which gets automagically converted to extension 1009
The call is established but the user application times out and detects a disconnect despite the calling phone not hanging up. In my wireshark trace it seems that SER is ignoring some form of keep-alive from the remote SIP server and this is causing the timeout. The lines of interest include 39, 42, 45, 50, 53, 56, 59
Lines 28 and others similar are on the loopback interface and are packets between port 5060 and 5070
Can someone please advise if the SIP protocol has problems and/or if SER configuration has problems?
22 0.218826 10.50.32.10 -> 127.0.0.1 SIP Request: REGISTER sip:localhost.localdomain 23 0.219570 127.0.0.1 -> 10.50.32.10 SIP Status: 200 OK (1 bindings) 24 19.472555 10.1.39.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1001@butler.fesa.sto;transport=udp, with session description 25 19.473394 10.50.32.10 -> 10.1.39.10 SIP Status: 100 trying -- your call is important to us 26 19.473596 10.50.32.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1009@10.50.32.10:5070;LINEID=1d5a67e38809, with session description 27 19.484244 10.50.32.10 -> 10.50.32.10 SIP Status: 100 Trying 28 19.725476 10.50.32.10 -> 10.50.32.10 SIP Status: 180 Ringing 29 19.725828 10.50.32.10 -> 10.1.39.10 SIP Status: 180 Ringing 32 21.770798 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 33 21.782437 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 38 21.789396 10.50.32.10 -> 10.1.39.202 RTCP Source port: 8001 Destination port: 16391 39 21.800069 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 40 22.278096 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 41 22.278713 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 42 22.298101 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 43 23.285536 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 44 23.288988 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 45 23.307839 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 48 25.298214 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 49 25.299105 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 50 25.317892 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 51 29.306496 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 52 29.306758 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 53 29.328420 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 54 33.314736 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 55 33.318736 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 56 33.338302 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 57 37.323175 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 58 37.324791 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 59 37.347936 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809
--> client detects disconnect here
Thanks
jeremy
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Thanks for this.
The problem is precisely that the app is not getting the ACK. It is being swallowed by SER. The wireshark traces show that.
The pattern is two systems retrying. The remote SIP server keeps resending an ACK which is swallowed The local application keeps sending a 200 OK which seems to get through SER
So my question is
Is this caused by my misunderstanding what SER does? or is it my faulty configuration for SER? or is it a bug? or something else?
Greger Viken Teigre wrote:
I'm on my mobile, so this is a quick suggestion: verify that your app receives the ACK. It seems to me that 200 Ok is resent. g-)
------- Original message ------- From: Jeremy A jeremy@electrosilk.net Sent: 28.11.'07, 4:22
Hello,
I'm need some help with SIP protocol / SER configuration to resolve a problem.
I have a system with a SER instance and a SIP client application running on the same box.
SER is 10.50.32.10:5060 APP is 10.50.32.10:5070 Remote SIP server 10.1.39.10 Remote phone is 10.1.39.202
The user agent is registered with the SER instance as extension 1009. It has aliases 1001-1008 and is actually called as 231x which maps onto 100x which then connects to extension 1009.
The remote phone makes a call to the user agent application via the remote SIP server and the SER instance. It dials 2311 which gets automagically converted to extension 1009
The call is established but the user application times out and detects a disconnect despite the calling phone not hanging up. In my wireshark trace it seems that SER is ignoring some form of keep-alive from the remote SIP server and this is causing the timeout. The lines of interest include 39, 42, 45, 50, 53, 56, 59
Lines 28 and others similar are on the loopback interface and are packets between port 5060 and 5070
Can someone please advise if the SIP protocol has problems and/or if SER configuration has problems?
22 0.218826 10.50.32.10 -> 127.0.0.1 SIP Request: REGISTER sip:localhost.localdomain 23 0.219570 127.0.0.1 -> 10.50.32.10 SIP Status: 200 OK (1 bindings) 24 19.472555 10.1.39.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1001@butler.fesa.sto;transport=udp, with session description 25 19.473394 10.50.32.10 -> 10.1.39.10 SIP Status: 100 trying -- your call is important to us 26 19.473596 10.50.32.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1009@10.50.32.10:5070;LINEID=1d5a67e38809, with session description 27 19.484244 10.50.32.10 -> 10.50.32.10 SIP Status: 100 Trying 28 19.725476 10.50.32.10 -> 10.50.32.10 SIP Status: 180 Ringing 29 19.725828 10.50.32.10 -> 10.1.39.10 SIP Status: 180 Ringing 32 21.770798 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 33 21.782437 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 38 21.789396 10.50.32.10 -> 10.1.39.202 RTCP Source port: 8001 Destination port: 16391 39 21.800069 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 40 22.278096 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 41 22.278713 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 42 22.298101 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 43 23.285536 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 44 23.288988 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 45 23.307839 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 48 25.298214 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 49 25.299105 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 50 25.317892 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 51 29.306496 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 52 29.306758 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 53 29.328420 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 54 33.314736 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 55 33.318736 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 56 33.338302 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 57 37.323175 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 58 37.324791 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 59 37.347936 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809
--> client detects disconnect here
Thanks
jeremy
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I forgot to mention I am using the ser.cfg logic sample from the dbtext module
http://www.iptel.org/ser/doc/modules/dbtext
# main routing logic
route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; };
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstreami and downstreami entities # use different transport protocol if (!method=="REGISTER") record_route();
# subsequent messages withing a dialogi should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; };
if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; };
# if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { # digest authentication if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; };
save("location"); break; };
lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; };
# native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1); }
route[1] { # send it out now; use statefuli forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
Jeremy A wrote:
Hello,
I'm need some help with SIP protocol / SER configuration to resolve a problem.
I have a system with a SER instance and a SIP client application running on the same box.
SER is 10.50.32.10:5060 APP is 10.50.32.10:5070 Remote SIP server 10.1.39.10 Remote phone is 10.1.39.202
The user agent is registered with the SER instance as extension 1009. It has aliases 1001-1008 and is actually called as 231x which maps onto 100x which then connects to extension 1009.
The remote phone makes a call to the user agent application via the remote SIP server and the SER instance. It dials 2311 which gets automagically converted to extension 1009
The call is established but the user application times out and detects a disconnect despite the calling phone not hanging up. In my wireshark trace it seems that SER is ignoring some form of keep-alive from the remote SIP server and this is causing the timeout. The lines of interest include 39, 42, 45, 50, 53, 56, 59
Lines 28 and others similar are on the loopback interface and are packets between port 5060 and 5070
Can someone please advise if the SIP protocol has problems and/or if SER configuration has problems?
22 0.218826 10.50.32.10 -> 127.0.0.1 SIP Request: REGISTER sip:localhost.localdomain 23 0.219570 127.0.0.1 -> 10.50.32.10 SIP Status: 200 OK (1 bindings) 24 19.472555 10.1.39.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1001@butler.fesa.sto;transport=udp, with session description 25 19.473394 10.50.32.10 -> 10.1.39.10 SIP Status: 100 trying -- your call is important to us 26 19.473596 10.50.32.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1009@10.50.32.10:5070;LINEID=1d5a67e38809, with session description 27 19.484244 10.50.32.10 -> 10.50.32.10 SIP Status: 100 Trying 28 19.725476 10.50.32.10 -> 10.50.32.10 SIP Status: 180 Ringing 29 19.725828 10.50.32.10 -> 10.1.39.10 SIP Status: 180 Ringing 32 21.770798 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 33 21.782437 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 38 21.789396 10.50.32.10 -> 10.1.39.202 RTCP Source port: 8001 Destination port: 16391 39 21.800069 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 40 22.278096 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 41 22.278713 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 42 22.298101 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 43 23.285536 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 44 23.288988 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 45 23.307839 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 48 25.298214 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 49 25.299105 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 50 25.317892 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 51 29.306496 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 52 29.306758 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 53 29.328420 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 54 33.314736 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 55 33.318736 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 56 33.338302 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 57 37.323175 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 58 37.324791 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 59 37.347936 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809
--> client detects disconnect here
Thanks
jeremy
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
If you have alias=ip-of-ser in your config, ACK with port 5070 in ruri will match uri==myself. The ACK should just be relayed. See example cfg for ser used for sems for an example. g-)
------- Original message ------- From: Jeremy A jeremy@electrosilk.net Sent: 28.11.'07, 9:59
I forgot to mention I am using the ser.cfg logic sample from the dbtext module
http://www.iptel.org/ser/doc/modules/dbtext
# main routing logic
route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; };
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstreami and downstreami entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialogi should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { # digest authentication if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; }; save("location"); break; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1);}
route[1] { # send it out now; use statefuli forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
Jeremy A wrote: Hello,
I'm need some help with SIP protocol / SER configuration to resolve a problem.
I have a system with a SER instance and a SIP client application running on the same box.
SER is 10.50.32.10:5060 APP is 10.50.32.10:5070 Remote SIP server 10.1.39.10 Remote phone is 10.1.39.202
The user agent is registered with the SER instance as extension 1009. It has aliases 1001-1008 and is actually called as 231x which maps onto 100x which then connects to extension 1009.
The remote phone makes a call to the user agent application via the remote SIP server and the SER instance. It dials 2311 which gets automagically converted to extension 1009
The call is established but the user application times out and detects a disconnect despite the calling phone not hanging up. In my wireshark trace it seems that SER is ignoring some form of keep-alive from the remote SIP server and this is causing the timeout. The lines of interest include 39, 42, 45, 50, 53, 56, 59
Lines 28 and others similar are on the loopback interface and are packets between port 5060 and 5070
Can someone please advise if the SIP protocol has problems and/or if SER configuration has problems?
22 0.218826 10.50.32.10 -> 127.0.0.1 SIP Request: REGISTER sip:localhost.localdomain 23 0.219570 127.0.0.1 -> 10.50.32.10 SIP Status: 200 OK (1 bindings) 24 19.472555 10.1.39.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1001@butler.fesa.sto;transport=udp, with session description 25 19.473394 10.50.32.10 -> 10.1.39.10 SIP Status: 100 trying -- your call is important to us 26 19.473596 10.50.32.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1009@10.50.32.10:5070;LINEID=1d5a67e38809, with session description 27 19.484244 10.50.32.10 -> 10.50.32.10 SIP Status: 100 Trying 28 19.725476 10.50.32.10 -> 10.50.32.10 SIP Status: 180 Ringing 29 19.725828 10.50.32.10 -> 10.1.39.10 SIP Status: 180 Ringing 32 21.770798 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 33 21.782437 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 38 21.789396 10.50.32.10 -> 10.1.39.202 RTCP Source port: 8001 Destination port: 16391 39 21.800069 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 40 22.278096 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 41 22.278713 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 42 22.298101 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 43 23.285536 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 44 23.288988 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 45 23.307839 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 48 25.298214 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 49 25.299105 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 50 25.317892 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 51 29.306496 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 52 29.306758 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 53 29.328420 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 54 33.314736 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 55 33.318736 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 56 33.338302 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 57 37.323175 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 58 37.324791 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 59 37.347936 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809
--> client detects disconnect here
Thanks
jeremy
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Greger Viken Teigre wrote:
If you have alias=ip-of-ser in your config, ACK with port 5070 in ruri will match uri==myself. The ACK should just be relayed. See example cfg for ser used for sems for an example. g-)
Unfortunately I am still quite puzzled by the SER configuration process, so I have not been able to work out exactly what to do. The ser/sems example uses pipes which doesn't help.
So far I have simply added a clause to always forward ACK packets. This is not sufficient.
The ACK gets through but now the BYE command gets rejected 404 not found on the user location lookup. I think this is caused by the aliases involved in the call ?
(Call is dialled as 2311@fesa.sto. It gets reformed to 1001@butler.fesa.sto and passed to the SER proxy for butler.fesa.sto. SER knows 1001 is an alias of registered user 1009 and sends the call to the user)
Here is a log of a call made on the SER machine butler.fesa.sto
25.202593 10.50.32.10 -> 127.0.0.1 SIP Request: REGISTER sip:localhost.localdomain <-- my application registering 25.213719 127.0.0.1 -> 10.50.32.10 SIP Status: 200 OK (1 bindings) 75.234982 10.1.39.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1001@butler.fesa.sto;transport=udp, with session description <-- invite to alias 75.255551 10.50.32.10 -> 10.1.39.10 SIP Status: 100 trying -- your call is important to us 75.255867 10.50.32.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1009@10.50.32.10:5070;LINEID=1d5a67e38809, with session description <-- Alias resolved and invite passed to registered phone 75.266591 10.50.32.10 -> 10.50.32.10 SIP Status: 100 Trying 75.576971 10.50.32.10 -> 10.50.32.10 SIP Status: 180 Ringing 75.578869 10.50.32.10 -> 10.1.39.10 SIP Status: 180 Ringing 77.632370 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 77.727289 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 77.745453 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 <-- ACK referencing originally dialed extension 77.746574 10.50.32.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 82.562176 10.1.39.10 -> 10.50.32.10 SIP Request: BYE sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 <--- BYE referencing originally dialed extension 82.563999 10.50.32.10 -> 10.1.39.10 SIP Status: 404 SER says Not Found
I am guessing (not being an expert in SIP) that the line ID LINEID=1d5a67e38809 allows SER to route the call to the correct extension despite the difference in SIP URI?
So I guess I need a bit of code that says that matches an existing LINEID and forwards the SIP message to the end user?
Here is the current routing logic based on the textdb example but with always forward ACK
# main routing logic
route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","SER says Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "SER says Message too big"); break; };
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstreami and downstreami entities # use different transport protocol
if (!method=="REGISTER") record_route();
# subsequent messages withing a dialogue should take the # path determined by record-routing
if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; };
if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; };
# if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") { # digest authentication if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; };
save("location"); break; };
if (method=="ACK") { route(1); break; }
lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; };
# native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "SER says Not Found"); break; }; };
append_hf("P-hint: usrloc applied\r\n"); route(1); }
route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
The BYE should have a Route header, which is used for routing. If it does not have a Route header, the UA originating the BYE must be fixed. Of course, you can hack the BYE by doing the same kind of alias rewriting as the INVITE, but it is not RFC-compliant. g-)
Jeremy A wrote:
Greger Viken Teigre wrote:
If you have alias=ip-of-ser in your config, ACK with port 5070 in ruri will match uri==myself. The ACK should just be relayed. See example cfg for ser used for sems for an example. g-)
Unfortunately I am still quite puzzled by the SER configuration process, so I have not been able to work out exactly what to do. The ser/sems example uses pipes which doesn't help.
So far I have simply added a clause to always forward ACK packets. This is not sufficient.
The ACK gets through but now the BYE command gets rejected 404 not found on the user location lookup. I think this is caused by the aliases involved in the call ?
(Call is dialled as 2311@fesa.sto. It gets reformed to 1001@butler.fesa.sto and passed to the SER proxy for butler.fesa.sto. SER knows 1001 is an alias of registered user 1009 and sends the call to the user)
Here is a log of a call made on the SER machine butler.fesa.sto
25.202593 10.50.32.10 -> 127.0.0.1 SIP Request: REGISTER sip:localhost.localdomain <-- my application registering 25.213719 127.0.0.1 -> 10.50.32.10 SIP Status: 200 OK (1 bindings) 75.234982 10.1.39.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1001@butler.fesa.sto;transport=udp, with session description <-- invite to alias 75.255551 10.50.32.10 -> 10.1.39.10 SIP Status: 100 trying -- your call is important to us 75.255867 10.50.32.10 -> 10.50.32.10 SIP/SDP Request: INVITE sip:1009@10.50.32.10:5070;LINEID=1d5a67e38809, with session description <-- Alias resolved and invite passed to registered phone 75.266591 10.50.32.10 -> 10.50.32.10 SIP Status: 100 Trying 75.576971 10.50.32.10 -> 10.50.32.10 SIP Status: 180 Ringing 75.578869 10.50.32.10 -> 10.1.39.10 SIP Status: 180 Ringing 77.632370 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with session description 77.727289 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with session description 77.745453 10.1.39.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 <-- ACK referencing originally dialed extension 77.746574 10.50.32.10 -> 10.50.32.10 SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 82.562176 10.1.39.10 -> 10.50.32.10 SIP Request: BYE sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809 <--- BYE referencing originally dialed extension 82.563999 10.50.32.10 -> 10.1.39.10 SIP Status: 404 SER says Not Found
I am guessing (not being an expert in SIP) that the line ID LINEID=1d5a67e38809 allows SER to route the call to the correct extension despite the difference in SIP URI?
So I guess I need a bit of code that says that matches an existing LINEID and forwards the SIP message to the end user?
Here is the current routing logic based on the textdb example but with always forward ACK
# main routing logic
route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","SER says Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "SER says Message too big"); break; }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstreami and downstreami entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialogue should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { # digest authentication if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; }; save("location"); break; }; if (method=="ACK") { route(1); break; } lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "SER says Not Found"); break; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1);}
route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
I seem to have fixed the problem with a 'hack' that looks for packets directed to port 5070 and sends them to route(1)
I think that is probably the correct solution and is RFC compliant? However it puzzles me that the test uri==myself doesn't take into account the port number.
NB my regex skills are low so the check for port 5070 is certainly sub-optimal, however it works :-)
Thanks for your help
New routing code:
if (uri==myself) {
if (method=="REGISTER") { # digest authentication if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; };
save("location"); break; };
lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; };
# send on any uri that goes to port 5070 - it's not us
if (search(":5070")) { route(1); break; }
# native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "SER says Not Found"); break; }; };
Greger V. Teigre wrote:
The BYE should have a Route header, which is used for routing. If it does not have a Route header, the UA originating the BYE must be fixed. Of course, you can hack the BYE by doing the same kind of alias rewriting as the INVITE, but it is not RFC-compliant. g-)
Jeremy A wrote:
Greger Viken Teigre wrote:
If you have alias=ip-of-ser in your config, ACK with port 5070 in ruri will match uri==myself. The ACK should just be relayed. See example cfg for ser used for sems for an example. g-)
Unfortunately I am still quite puzzled by the SER configuration process, so I have not been able to work out exactly what to do. The ser/sems example uses pipes which doesn't help.
So far I have simply added a clause to always forward ACK packets. This is not sufficient.
The ACK gets through but now the BYE command gets rejected 404 not found on the user location lookup. I think this is caused by the aliases involved in the call ?
(Call is dialled as 2311@fesa.sto. It gets reformed to 1001@butler.fesa.sto and passed to the SER proxy for butler.fesa.sto. SER knows 1001 is an alias of registered user 1009 and sends the call to the user)
Here is a log of a call made on the SER machine butler.fesa.sto
Make sure to NOT include alias=ipaddress. However, there's probably something wrong with the BYE, because it should have Route headers. uri=myself is fairly simple and static, so normally you would like to use the domain module and use is_from_local() and is_uri_host_local().
BTW, search() searches the full message, uri=~"sip:.*@.*:5070" would be more precise and only search the uri. g-)
Jeremy A wrote:
I seem to have fixed the problem with a 'hack' that looks for packets directed to port 5070 and sends them to route(1)
I think that is probably the correct solution and is RFC compliant? However it puzzles me that the test uri==myself doesn't take into account the port number.
NB my regex skills are low so the check for port 5070 is certainly sub-optimal, however it works :-)
Thanks for your help
New routing code:
if (uri==myself) { if (method=="REGISTER") { # digest authentication if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; }; save("location"); break; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; };# send on any uri that goes to port 5070 - it's not us
if (search(":5070")) { route(1); break;}
# native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "SER says Not Found"); break; }; };Greger V. Teigre wrote:
The BYE should have a Route header, which is used for routing. If it does not have a Route header, the UA originating the BYE must be fixed. Of course, you can hack the BYE by doing the same kind of alias rewriting as the INVITE, but it is not RFC-compliant. g-)
Jeremy A wrote:
Greger Viken Teigre wrote:
If you have alias=ip-of-ser in your config, ACK with port 5070 in ruri will match uri==myself. The ACK should just be relayed. See example cfg for ser used for sems for an example. g-)
Unfortunately I am still quite puzzled by the SER configuration process, so I have not been able to work out exactly what to do. The ser/sems example uses pipes which doesn't help.
So far I have simply added a clause to always forward ACK packets. This is not sufficient.
The ACK gets through but now the BYE command gets rejected 404 not found on the user location lookup. I think this is caused by the aliases involved in the call ?
(Call is dialled as 2311@fesa.sto. It gets reformed to 1001@butler.fesa.sto and passed to the SER proxy for butler.fesa.sto. SER knows 1001 is an alias of registered user 1009 and sends the call to the user)
Here is a log of a call made on the SER machine butler.fesa.sto
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Greger V. Teigre -
Greger Viken Teigre
-
Jeremy A