[asterisk-dev] Strange code in chan_sip.c (1.4) sip_xmit - network retry in 1 ms on REGISTER socket failures

[Olle E. Johansson]

7 sep 2009 kl. 18.02 skrev Klaus Darilion:

> Hi Olle!
>
> That might be the cause of the problem I reported some time ago:
> http://www.mail-archive.com/asterisk-dev@lists.digium.com/ 
> msg38618.html
>
Yes, it is. That code needs to be fixed soon. Follow the bug report :-)

/O

> regards
> klaus
>
> Olle E. Johansson schrieb:
>>  1818 /*! \brief Transmit SIP message */
>>  1819 static int __sip_xmit(struct sip_pvt *p, char *data, int len)
>>  1820 {
>>  1821         int res;
>>  1822         const struct sockaddr_in *dst = sip_real_dst(p);
>>  1823         res = sendto(sipsock, data, len, 0, (const struct
>> sockaddr *)dst, sizeof(struct sockaddr_in))      ;
>>  1824
>>  1825         if (res == -1) {
>>  1826                 switch (errno) {   1827                 case
>> EBADF:             /* Bad file descriptor - seems like this is
>> generated when th      e host exist, but doesn't accept the UDP  
>> packet
>> */
>>  1828                 case EHOSTUNREACH:      /* Host can't be
>> reached */
>>  1829                 case ENETDOWN:          /* Inteface down */
>>  1830                 case ENETUNREACH:       /* Network failure */
>>  1831                 case ECONNREFUSED:      /* ICMP port
>> unreachable */
>>  1832                         res = XMIT_ERROR;       /* Don't bother
>> with trying to transmit again */
>>  1833                 }
>>  1834
>>  1835                 if (p->registry && p->registry->regstate <
>> REG_STATE_REGISTERED) {
>>  1836                         AST_SCHED_DEL(sched, p->registry-
>>> timeout);
>>  1837                         p->registry->needdns = TRUE;
>>  1838                         p->registry->timeout =
>> ast_sched_add(sched, 1, sip_reg_timeout, p->registry);
>>  1839                 }
>>  1840         }
>>
>>
>> Since I don't have access to svnview, it's too hard to trace when the
>> lines 1835-1839 was added. Somehow it reschedules a REGISTER in the
>> middle of the "send to socket" function, bypassing a lot of other  
>> code
>> that handles errors on this layer. It's extremely aggressive. What
>> kind of network-related errors would possibly be resolved in 1 ms and
>> can't wait for normal SIP retransmit?
>>
>> I need to understand where this is coming from and why, since there's
>> a bug report in https://issues.asterisk.org/view.php?id=15540.
>>
>> I think we should propably just remove it or move it somewhere else.
>> For some reason, it doesn't exist at all in 1.6 or trunk.
>>
>> /O
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
>> Register Now: http://www.astricon.net
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
> Register Now: http://www.astricon.net
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

---
* Olle E Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden