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

[Olle E. Johansson]

  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