[Serusers] Unexpected disconnect - lost SIP packets?
Greger Viken Teigre
greger at teigre.com
Wed Nov 28 10:10:58 CET 2007
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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 10.50.32.10:5070;LINEID=1d5a67e38809
>
> --> client detects disconnect here
>
> Thanks
>
> jeremy
>
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
More information about the sr-users
mailing list