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

Daniel-Constantin Mierla miconda at gmail.com
Wed Oct 11 10:59:46 CEST 2017


A reply is re-sent in case of retransmission if the transaction of the
first subscribe sent out already a reply, otherwise no -- you can see in
the c code you pasted the function to retransmit reply.

Anyhow, it is up to yiou if you want to do retransmission handling as
per default config, you can skip that part of config for subscribe by
enclosing it inside an if block like:

if(!is_method("SUBSCRIBE")) {
  ...
}

Cheers,
Daniel

On 11.10.17 10:43, Jack Wang wrote:
> 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
> <mailto: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 List
>>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>     -- 
>     Daniel-Constantin Mierla
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>     Kamailio Advanced Training - www.asipto.com <http://www.asipto.com>
>     Kamailio World Conference - www.kamailioworld.com <http://www.kamailioworld.com>
>
>

-- 
Daniel-Constantin Mierla
www.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/885a6016/attachment.html>


More information about the sr-users mailing list