Home / server / Questions / 219369
In Process
sunil221
Asked: 2011-01-06 04:12:10 +0800 CST

not able to register sip user on red5server, using red5phone

  • 772

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:[email protected]:5072

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:[email protected]:5072> (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:[email protected]:5072>
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.

linux asterisk sip red5

2 Answers

  1. 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.

    • 2

  2. 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...).

    Examples:

    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 "[email protected]" "port 5060"

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

    • 2