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

[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

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