[Serusers] NAT Related Voicemail Timeout Problem (HELP!)

[Corey S. McFadden]

Greger,

Thanks for the response.  To answer your questions, the original INVITE is 
coming from 5060.  After the timeout the second INVITE is a mystery.  I'm 
looking into the ;lr=on question but it definitely looks like the OK isn't 
getting to the GW.

I thought there might be an independent timeout on the GW messing with 
things but we turned down the fr_inv_timer to 4 and that had no effect.  
As soon as the failure route hit Asterisk the call drops for the caller.

I'm inclined to think it might have something to do with the rtpproxy 
because we've discovered another situation: two phones behind the same NAT 
registering to SER can't call each other.  They can ring each other but 
the calls never actually connect.

Here is some SER debug:
 5(75891) contact_parser(): Empty body
 5(75891) parse_contact(): Error while parsing
 5(75891) get_contact_uri: Error while parsing Contact body
 2(75888) contact_parser(): Empty body
 2(75888) parse_contact(): Error while parsing
 2(75888) get_contact_uri: Error while parsing Contact body
 2(75888) ERROR: add_uac: maximum number of branches exceeded
 2(75888) ERROR: t_forward_nonack: failure to add branches
 2(75888) ERROR: w_t_relay (failure mode): forwarding failed
 2(75888) ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL)


If anyone can provide any more insight as to what we might be doing wrong 
here we would certainly appreciate it.

Thanks again,
-Corey




On Fri, 2 Sep 2005, Greger V. Teigre wrote:

> Hi Corey,
> A few comments:
> - It seems that after the timeout, a new INVITE is generated to the UA, 
> right before the forwarding to Asterisk. Is this just noise or part of the 
> actual call you documented?
> - The record routing and path of the messages look fine AFAICS, but you 
> don't mention one crucial point: Does the caller receive the OK or not? You 
> assume it is a NAT problem, but are you sure? Maybe the caller discards the 
> message for some reason?
> - You haven't shown the initial INVITE from .7. Does it originate on port 
> 5060?  Some GWs will be asynchronous and expect reply on the high UDP port 
> used for the INVITE. Your NAT detection may then detect the GW as NATed and 
> rewrite, which may cause a problem.
> - I remember a problem where Asterisk was involved where ;lr=on caused a 
> problem. I cannot remember if it is relevant, but you may want to search in 
> the archives
> - A log from the caller would tell you if the OK is received or dropped
> 
> g-)
> 

<snip>
 


*********************************************
This message has been scanned for viruses and
dangerous content, and is believed to be clean.