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

[Jack Wang]

Okay, I see.
Thanks a lot. :D

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

> 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>:
>
>> 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
>>
>>
>
> --
> 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/af68712a/attachment.html>