[SR-Users] [4.2.8] SUBSCRIBE message was not handled

[Jack Wang]

Yes, the SUBSCRIBE was sent continuously 2~3 times captured by wireshark,
I tested using Ekiga as the sip client on windows 7.

However, after I rebooted the pc and re-test  this,
it only send one SUBSCRIBE now no matter how I tried,
even I changed the codes back.

And as you said, "it means that the same SUBSCRIBE was already processed...
",
but I think it should send 200 OK and the NOTIFY back in a normal situation
if it is indeed processed,
rather than stopping there when it received a retransmitted SIP message.

I can not generate the situation now, but I'll keep watching for this.

Thanks. :)

2017-10-11 15:52 GMT+08:00 Daniel-Constantin Mierla <miconda at gmail.com>:

> Hello,
>
> it means that the same SUBSCRIBE was aready processed and the current one
> is a retransmission. Can you look at sip network traffic (using ngrep,
> sngrep, ...) and see if there are two SUBSCRIBE requests received?
>
> Cheers,
> Daniel
>
> On 05.10.17 11:34, Jack Wang wrote:
>
> Hello everyone,
>
> According to the routing flow set in kamailio.cfg
>
>  # handle retransmissions
>  if(t_precheck_trans()) {
>              t_check_trans();
>              exit;
>  }
> t_check_trans();
> After I traced the flow it seems that SUBSCRIBE message failed on t_check_trans()
> and stopped there.
> I add some logs to keep tracing this function and found that:
> int t_check_trans(struct sip_msg* msg) { struct cell* t; int branch; int
> ret; /* already processing a T */ if(is_route_type(FAILURE_ROUTE) ||
> is_route_type(BRANCH_ROUTE) || is_route_type(BRANCH_FAILURE_ROUTE) ||
> is_route_type(TM_ONREPLY_ROUTE)) { return 1; } if
> (msg->first_line.type==SIP_REPLY) { branch = 0; ret = (t_check_msg( msg ,
> &branch)==1) ? 1 : -1; tm_ctx_set_branch_index(branch); return ret; }
> else if (msg->REQ_METHOD==METHOD_CANCEL) { return w_t_lookup_cancel(msg,
> 0, 0); } else { switch(t_check_msg(msg, 0)){ case -2: /* possible e2e ack
> */ return 1; case 1: /* found */ t=get_t(); if
> (msg->REQ_METHOD==METHOD_ACK){ /* ack to neg. reply or ack to local trans.
> => process it and end the script */ /* FIXME: there's no way to distinguish
> here between acks to local trans. and neg. acks */ if
> (unlikely(has_tran_tmcbs(t, TMCB_ACK_NEG_IN))) run_trans_callbacks(TMCB_ACK_NEG_IN,
> t, msg, 0, msg->REQ_METHOD); t_release_transaction(t); } else { /* is a
> retransmission */ if (unlikely(has_tran_tmcbs(t, TMCB_REQ_RETR_IN)))
> run_trans_callbacks(TMCB_REQ_RETR_IN, t, msg, 0, msg->REQ_METHOD);
> t_retransmit_reply(t); } /* no need for UNREF(t); set_t(0) - the
> end-of-script t_unref callback will take care of them */ return 0; /* exit
> from the script */ <---------------------------- THE POINT !! } /* not
> found or error */ } return -1; }
>
> If the line "return 0; /* exit from the script */" was changed to "return
> 1; /* exit from the script */" , it works ---- means that the configuration
> script can keep being proceeded now.
> Any suggestions?
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - www.asipto.com
> Kamailio World Conference - www.kamailioworld.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171011/7dfa1df7/attachment.html>