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.