2 Sep
2005
2 Sep
'05
8:27 p.m.
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.