Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I start the red5,

and then i start red5phone

i try to register sip user , details i provide are

    username = 999999
    password = ****
    ip = asteriskserverip

And I got

-- Registering contact -- sip:999999@

The right contact could be

-- Registering contact -- sip :99999@asteriskserverip

This is the log:

SipUserAgent - listen -> Init...
Red5SIP register
[SIPUser] register
RegisterAgent: Registering contact <sip:99999@> (it expires in 3600 secs)
RegisterAgent: Registration failure: No response from server.
[SIPUser] SIP Registration failure Timeout
RegisterAgent: Failed Registration stop try.
Red5SIP Client leaving app 1
Red5SIP Client closing client 35C1B495-E084-1651-0C40-559437CAC7E1
Release ports: sip port 5072 audio port 3002
Release port number:5072
Release port number:3002
[SIPUser] close1
[SIPUser] hangup
[SIPUser] closeStreams
RTMPUser stopStream
[SIPUser] unregister
RegisterAgent: Unregistering contact <sip:99999@>
SipUserAgent - hangup -> Init...
SipUserAgent - closeMediaApplication -> Init...
[SIPUser] provider.halt
RegisterAgent: Registration failure: No response from server.
[SIPUser] SIP Registration failure Timeout

Please let me know if i am doing anything wrong.

share|improve this question

migrated from Jan 6 '11 at 12:08

This question came from our site for computer enthusiasts and power users.

Somehow this question got 11 upvotes. What exactly is the programming question here? – Duck Jan 5 '11 at 15:54
That sysadmin question :) – Vitaly Nikolaev Jan 6 '11 at 16:08

What I would suggest doing is do a packet capture on both the phone and the server side, and then analyse the captures using WireShark.

Wireshark has exceptionally good interpretation of VoIP traffic and will break down the SIP packets for you into easy to read chunks.

From there, you can tell if your STUN server is incorrect (if you're using STUN), or if there's something weird going on with the connection packet, and then use that to narrow the situation down.

The reason for running the capture on both ends, is that I've seen some well-meaning "SIP-Aware" firewalls manipulate SIP packets incorrectly which caused no end of headaches, but I could then tell that the packets going into the firewall were different than what was leaving the firewall, which was a giveaway.

share|improve this answer

Packet capture (thsark/ngrep) holds the answers you seek.

I would say the server is not receiving the SIP packet for registration or the client can't receive the response, judging by

'RegisterAgent: Registration failure: No response from server.'

Verify this by using tshark/ngrep/tcpdump on the server you're attempting to register to. If you do see it landing on the server but the server never responds, check it's log files. Verify there are no firewall rules on the server block it. It will show up sniffing but the application will not respond to it.

Standard SIP will be on port 5060, most likely UDP but occasionally TCP (I'm looking at you Microsoft...).


tshark -i eth0 "port 5060"
ngrep -q -W byline "" "port 5060"
tcpdump "port 5060"

ngrep is handy if you have lots of other valid SIP traffic but need to quickly read some of it.

ngrep -q -W byline "5025851212" "port 5060"

This for example would look for a specific phone number, or

ngrep -I CAPTURED.PCAP -q -W byline "" "port 5060"

a specific call-id inside of a precaptured file: CAPTURED.PCAP

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.