I have an * 1.6.1.20, with chan_ss7 and E1 to a ericsson switch. My sip clients make calls to the PSTN via the SS7 link.
With one pbx (astra intelligate) that I just connected, I am getting very strange results.
Here is the dialog - traced with wireshark
Client / Asterisk
INVITE ->
<- UNAUTH
<- UNAUTH
<- UNAUTH
<- UNAUTH
<- UNAUTH
ACK ->
INVITE ->
<- TRYING
ACK ->
ACK ->
ACK ->
ACK ->
<- Session in Progress 183
(RTP flow starts)
<- Ringing 180
<- OK 200
<- OK 200
<- OK 200
<- OK 200
<- OK 200
<- OK 200
RTP one way, from client to asterisk - no more rtp trafic from asterisk to client
ICMP Host unreachable
-> BYE
<- Call leg does not exist, 481
On the CLI, I get a no reply to critical packet, call hang up… but it appears as it the the remote end terminating the call.
My first question would be… why would asterisk resend initially 5 times the ‘UNAUTH’ messages, within 1.5 second ?
The wireshark is on the asterisk server, which I control. I have little access/control to client site.
I have recorded the conversation on the server (mixmonitor), and the audio is fine, both ways, and clearly shows that both parties can hear each other.
the server is not a VM, it runs on dell poweredge, with centos 5.3. I have tried to attached the dialog as a file but could see the link (I must be blind) so its copied & pasted here.
What tickles me is that my server communicates correctly with other client / pbx, just this one is messy. I therefore assume my network end is correct. So why is it my side that first resends a packet 4 times ?
The timing would be very useful (from the log file, rather than the console). It looks like the remote side as been using much too short a timeout when waiting for ACKs.
I would say the problem was entirely on the non-Asterisk side (which is acting as a UAS (user agent server) in this case), and even then, should only result in excess traffic.
However, you keep providing incomplete traces. E.g., in the wire shark trace, I can see the UAS has sent OKs at intervals of only a few milliseconds, but I can’t see the INVITE, to see if it started doing this immediately.
First of all, many thanks for the valuable help provided here. I do appreciate this.
I have tried to “extract” the packets from wireshark in a format that can be read. I am posting here below the results.
I also went to the client premises, and tried to make a number of calls with a softphone instead of his pbx. They all went well.
My guess is either something is wrong with the pbx itself (An Aastra 5000 - any clues ?) or with the client network, which only happens once in a while - and not when I was there.
Anyway, I am not sure it makes sense to keep asking help on this issue, I am posting the traces just in case someone has been tickled and wants to see them !
There seems to be a big delay before Asterisk sees the response, then it answers them quickly.
One theory is that there a dodgy DNS configuration that is forcing Asterisk to re-lookup a domain name (excessively short time to live), combined with sluggish responses to DNS requests.
Otherwise you need to provide debug output from Asterisk itself.
There may be some sort of partial deadlock, but I’d expect that to affect everybody.
Note there is nothing obviously wrong with the order of the events - there are no causality violations, any missing packets, or any excess ones, other than what would be explained by the packet getting backlogged in an internal queue.
What I dont get is why does my asterisk send 5 x Unauthorized after it receives the first invite (every half second or so)
It seems that the remote (client inviting) is slow to ACK the first invite, but Asterisk only waits 0.283 secs before resending the invite - While my T1 is set to 500ms -
OK I got the two sides mixed up. If your side is sending the multiple unauthorised’s, it is because the other side is failing to send an ACK promptly. There is a reasonable delay between them.
In that case, there is network congestion, or a processing delay at the remote side. If there is a DNS problem, it will with your DNS, e.g. you have a very short TTL, to compensate for an unstable address, but your DNS server is overloaded, or poorly connected.
SIP reliable responses are repeated, at escalating intervals, until either a maximum number is reached, or an ACK is received.
Asterisk is responding properly to an extremely late ACK.
