[demo App] Cannot send rtp packet

Help
Anonymous
2012-05-03
2012-12-06

  • Anonymous
    2012-05-03

    I've already commented on the news post but I'm not sure that wil get read so I'm posting this here.

    I have build the demo App by following its instructions on te following page
    http://peers.sourceforge.net/2011/12/01/peers-evolutions/

    my setup is:
    - Win 7 pc, IP192.168.2.100, running eclipsewith the demo APP
    - Linux server, IP192.168.2.8, running sipp
    They are connected both on the lan side to a NAT router.
    Windows firewall is disabled during testing.

    the profile part of my peers.xml configuration is
    userpart = demo
    domain = pc-durandal (=192.168.2.100, my pc)
    password=demo
    outboundproxy=
    port=6060

    The stand-alone peers application runs fine, sound and all.

    When copying the App class I get an Ambigious Contstructor compiler error on the line

    UserAgent userAgent = new UserAgent(this, null, null);
    

    but I solved it by adding "." as second parameter.

    When I run the demo App I see sipp answering the call, however I get no sound.
    I get these events (and printed the sipRequests):

    ringing:-----------------
    SIP/2.0 180 Ringing
    Via: SIP/2.0/UDP 192.168.2.100:6060;rport;branch=z9hG4bKtnGiBN8RF
    From: <sip:demo@pc-durandal>;tag=w4IUWKvs
    To: <sip:serv@192.168.2.8>;tag=31355SIPpTag012
    Call-ID: NdYeRBIV-1336008679215@pc-durandal
    CSeq: 1 INVITE
    Contact: <sip:127.0.1.1:5060;transport=UDP>
    Content-Length: 0
    caleePickup--------------
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 192.168.2.100:6060;rport;branch=z9hG4bKtnGiBN8RF
    From: <sip:demo@pc-durandal>;tag=w4IUWKvs
    To: <sip:serv@192.168.2.8>;tag=31355SIPpTag012
    Call-ID: NdYeRBIV-1336008679215@pc-durandal
    CSeq: 1 INVITE
    Contact: <sip:127.0.1.1:5060;transport=UDP>
    Content-Type: application/sdp
    Content-Length: 129
    v=0
    o=user1 53655765 2353687637 IN IP4 127.0.1.1
    s=-
    c=IN IP4 127.0.1.1
    t=0 0
    m=audio 6000 RTP/AVP 0
    a=rtpmap:0 PCMU/8000
    

    Looking at the log, everything looks fine until an exception occurs
    (with rtp, which likely explains the no-sound part):

    2012-05-03 03:31:19,132 INFO  [main] starting user agent [myAddress: 192.168.2.100, sipPort: 6060, userpart: demo, domain: pc-durandal]
    2012-05-03 03:31:19,178 INFO  [main] added datagram socket 192.168.2.100:6060/UDP
    2012-05-03 03:31:19,180 INFO  [main] added 192.168.2.100:6060/UDP: net.sourceforge.peers.sip.transport.UdpMessageReceiver@4b5d060d to message receivers
    2012-05-03 03:31:19,223 DEBUG [Timer-3] UdpMessageSender.sendBytes
    2012-05-03 03:31:19,223 DEBUG [Timer-3] UdpMessageSender.sendBytes packet created
    2012-05-03 03:31:19,223 DEBUG [Timer-3] UdpMessageSender.sendBytes packet sent
    2012-05-03 03:31:19,225 DEBUG [main] SM z9hG4bKtnGiBN8RF|INVITE [InviteClientTransactionStateInit -> InviteClientTransactionStateCalling] setState
    2012-05-03 03:31:19,226 DEBUG [main] UdpMessageSender.sendMessage
    2012-05-03 03:31:19,226 DEBUG [main] UdpMessageSender.sendBytes
    2012-05-03 03:31:19,226 DEBUG [main] UdpMessageSender.sendBytes packet created
    2012-05-03 03:31:19,226 DEBUG [main] UdpMessageSender.sendBytes packet sent
    2012-05-03 03:31:19,227 DEBUG [main] InviteClientTransaction.start
    2012-05-03 03:31:19,228 DEBUG [Thread-4] ClientTransaction = net.sourceforge.peers.sip.transaction.InviteClientTransaction@1ef0a6e8
    2012-05-03 03:31:19,228 DEBUG [Thread-4] SM z9hG4bKtnGiBN8RF|INVITE [InviteClientTransactionStateCalling -> InviteClientTransactionStateProceeding] setState
    2012-05-03 03:31:19,233 DEBUG [Thread-4] Contact: <sip:127.0.1.1:5060;transport=UDP>
    2012-05-03 03:31:19,233 DEBUG [Thread-4] SM NdYeRBIV-1336008679215@pc-durandal|w4IUWKvs|31355SIPpTag012 [DialogStateInit -> DialogStateEarly] setState
    2012-05-03 03:31:19,234 DEBUG [Thread-4] ClientTransaction = net.sourceforge.peers.sip.transaction.InviteClientTransaction@1ef0a6e8
    2012-05-03 03:31:19,235 DEBUG [Thread-4] SM z9hG4bKtnGiBN8RF|INVITE [InviteClientTransactionStateProceeding -> InviteClientTransactionStateTerminated] setState
    2012-05-03 03:31:19,235 DEBUG [Thread-4] Contact: <sip:127.0.1.1:5060;transport=UDP>
    2012-05-03 03:31:19,238 DEBUG [Thread-4] openAndStartLines
    2012-05-03 03:31:19,319 DEBUG [Thread-4] playback codec:a=rtpmap:0 PCMU/8000
    2012-05-03 03:31:19,321 DEBUG [Thread-4] SM NdYeRBIV-1336008679215@pc-durandal|w4IUWKvs|31355SIPpTag012 [DialogStateEarly -> DialogStateConfirmed] setState
    2012-05-03 03:31:19,324 DEBUG [Thread-4] UdpMessageSender.sendMessage
    2012-05-03 03:31:19,324 DEBUG [Thread-4] UdpMessageSender.sendBytes
    2012-05-03 03:31:19,324 DEBUG [Thread-4] UdpMessageSender.sendBytes packet created
    2012-05-03 03:31:19,324 DEBUG [Thread-4] UdpMessageSender.sendBytes packet sent
    2012-05-03 03:31:19,340 ERROR [Thread-9] cannot send rtp packet
    java.net.BindException: Cannot assign requested address: Datagram send failed
        at java.net.DualStackPlainDatagramSocketImpl.socketSend(Native Method)
        at java.net.DualStackPlainDatagramSocketImpl.send(DualStackPlainDatagramSocketImpl.java:117)
        at java.net.DatagramSocket.send(DatagramSocket.java:675)
        at net.sourceforge.peers.rtp.RtpSession.send(RtpSession.java:116)
        at net.sourceforge.peers.media.RtpSender.run(RtpSender.java:150)
        at java.lang.Thread.run(Thread.java:722)
    

    The exception keeps repeating.

    I have no idea what causes this or how to fix it and get the demo running.
    Would appreciate some help.

    Thanks :)

     
  • hi,

    sorry for belated answer, can you make sure rtp port configured in peers.xml is not already used on your eclipse/app host?. Default value is 8000, which is the same as sipp rtp port with rtp_echo option. This should not be the cause of your issue as you said your sipp instance is running on another host, but trying to figure out. Are you running only one instance of your app or peers on the same host? You can run several instances, but make sure you have not port conflicts.

    Can you make sure your ip address is the right one? Maybe you have to configure network <address> field in peers.xml. Peers tries to guess your host ip address, but sometimes it fails. This field overrides this "automatic" host ip address discovery.

     

  • Anonymous
    2012-05-03

    Hi, thanks for your answer Yohann.

    No luck yet.

    I am running just one instance of the App in eclipse, and no Peers application. Also, yes, sipp runs on the server down the hall (my only linux machine and i'm not running cygwin).

    The IP address of my machine running eclipse/App as known by peers is correct. It's 192.168.2.100 (fixed in DHCP) and pc-durandal translates to it. It had also correctly given in the first line of the peers log, however I have set the IP in the <address> element anyway (which does not fix this).
    The SIP port is what i've told peers to use (6060), which is correct, is unused when starting the demo.
    Netstat tells me the port 8000 used for rtp is not used on the eclipse/App machine, until I start the demo. When I do that, it is connected (but in some hybrid IPv4/v6 form I don't recognise):

     UDP    [::ffff:192.168.2.100]:6060  *:*
     UDP    [::ffff:192.168.2.100]:8000  *:*
    

    The IP address of the server ('server' or 192.168.2.8) is not shown in the peers log but it is shown in the event messages.

    To: <sip:serv@192.168.2.8>;tag=31355SIPpTag012
    

    So peers should send to sipp, and that works because sipp picks up.

    One thing I don't understand is the contact field of the sip requests (in the dump in the opening post):

    Contact: <sip:127.0.1.1:5060;transport=UDP>
    

    Where does the 127.0.1.1 come from?

    Also, but I think this is a side issue, when closing sipp on my server (after running through the night), i got the following message

    2012-05-03      16:03:21:968    1336053801.968477: Aborting call on unexpected message for Call-Id '600282104714149100611795': while expecting 'INVITE' (index 0), received 'OPTIONS sip:100@83.98.233.229 SIP/2.0
    Via: SIP/2.0/UDP 127.0.0.2:5060;branch=z9hG4bK-642446094;rport
    Content-Length: 0
    From: "sipvicious"<sip:100@1.1.1.1>; tag=3533363265396535313363340131343233343932303135
    Accept: application/sdp
    User-Agent: friendly-scanner
    To: "sipvicious"<sip:100@1.1.1.1>
    Contact: sip:100@127.0.0.2:5060
    CSeq: 1 OPTIONS
    Call-ID: 600282104714149100611795
    Max-Forwards: 70
    

    This seems to be some spider coming from outside through the router over the WAN, but I don't think it caused the issue.

    So, no luck yet. Is it possible and worth trying to change the rtp port in sipp (so I can set both on another port)?
    Do you have another idea?

    Thanks

     

  • Anonymous
    2012-05-03

    I have solved it.

    The line from the sipRequest that I didn't understand gave it away.

    Contact: <sip:127.0.1.1:5060;transport=UDP>
    

    Googling brought me to this

    Some software (e.g., GNOME) expects the system hostname to be resolvable to an IP address with a canonical fully qualified domain name. This is really improper because system hostnames and domain names are two very different things; but there you have it. In order to support that software, it is necessary to ensure that the system hostname can be resolved. Most often this is done by putting a line in /etc/hosts containing some IP address and the system hostname. If your system has a permanent IP address then use that; otherwise use the address 127.0.1.1.

    I looked in /etc/hosts on the server and it contained
    127.0.1.1   server
    sipp uses that to export 127.0.1.1 in his sip reply, so that seems like a bug in linux or sipp.
    In any case, changing the server in the host file  to 192.168.2.8 made all the difference as you can see in the contact header of the pickup event:

    caleePickup--------------
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 192.168.2.100:6060;rport;branch=z9hG4bKmN2Fp3NxA
    From: <sip:demo@pc-durandal>;tag=IlG5B86R
    To: <sip:serv@192.168.2.8>;tag=8200SIPpTag011
    Call-ID: RBTE8EyM-1336067100317@pc-durandal
    CSeq: 1 INVITE
    Contact: <sip:192.168.2.8:5060;transport=UDP>
    Content-Type: application/sdp
    Content-Length: 133
    v=0
    o=user1 53655765 2353687637 IN IP4 192.168.2.8
    s=-
    c=IN IP4 192.168.2.8
    t=0 0
    m=audio 6000 RTP/AVP 0
    a=rtpmap:0 PCMU/8000
    

    Apparently peers uses that as the address to connect the rtp socket to.

    Sound echo works now. I am happy.

    Two more questions if you please
    1) I am working towards a small SIP user agent, no user interface, that automatically answers calls until the other side hangs up. Is this possible with the peers library? Should I face any problems?
    2) Is there a javadoc available?

    Thanks a bunch for your help and your work in the project :)

     
  • yes, i've seen your post this afternoon but sourceforge login was not working at that time…
    you found the 127.0.1.1 issue so it's okay now. Actually, peers does not use ip address from sip Contact header to send rtp packets, but the ip address provided in SDP offer, in SIP message body, which was also 127.0.1.1.

    1) yes it's possible, you should not face any feasibility issue. If you want, you can configure peers to send back rtp traffic (echo mode) to the remote party.

    2) no, sorry, no javadoc, but a detailed documentation here.

    Actually in the beginning peers was not intended to be an api. I tried to design it as clean as possible, so it can now be used as an api. I think the reason why many people use it is its small footprint and its kiss philosophy.

     

  • Anonymous
    2012-05-03

    Yes I like that kiss philosophy. While I planned to use peers itself and strip away anything I didn't need I was glad I found the demo which attended me to the api.

    One question out of curiosity, what made you decide on your own logger in stead of the standard java logging or Log4j?

     
  • I wanted peers to have no dependency but java standard api or java extension api. You could argue that I could have used java specification api Logger, but found it a bit complicated for my needs.

     

  • Anonymous
    2012-05-04

    Fair enough. Could I set up the peers logger to output only to console (without changing the peers code)?
    I can't use disk access for my project. Configuration has an interface that I can implement, but logging is a class that can't be overriden.

    Also, I've came into a problem where calls could not be set up if I fill in the outboundProxy field in the configuration. I am using out-of-the-box peers and I have my own registration server. This is not a full proxy, however, just using it for registration sto show on a website.

    I have SJphone set up on one end, registered to my registration server, and peers on the other end, registered too using a password and the outboundProxy field in the configuration.

    When I call peers from SJphone all I see in the logs is SJphone sending INVITEs to peers, but peers is not picking it up.
    Peers RECIEVES the INVITEs from SJphone, but then SENDs the '180 ringing' response to the outboundProxy in stead of to SJphone. The outboundProxy does nothing and the cycle starts again.

    What I need is for peers to register at the Registrar but NOT to use a proxy.
    Is that possible? If so, how?
    I'd love the outboundProxy field split into a registrar and a proxy field. SJphone allows for this.

    Thanks :)

     

  • Anonymous
    2012-05-04

    Another problem.
    I use my proxy to send BYE commands to both clients. For some reason (bug) it sends a second BYE to peers for the same dialog. Peers throws an IllegalStateException which is ok but after that peers won't respond to any subsequent incoming calls.
    Does throwing the exception kill the listening thread, and can I get around this?

     
  • Logger

    no unfortunately, as you can see, you can't change peers logger behavior without modifying it. Maybe you can redirect everything to /dev/null if you are on a linux host? I don't know how to do that without stdout or stderr use.

    registration issue

    just use the ip address or fqdn of your custom registrar in domain field in peers.xml and let outboundProxy empty.

    When you fill outboundProxy you instruct your sip user agent to send all sip traffic to this sip proxy.

    could you post transport.log?

    proxy sending bye

    So you have your custom registrar on a sip node and a custom sip proxy on another node?

    For your information, a sip proxy NEVER sends a bye request of its own after a call has been established. I guess you are trying to implement a b2bua which can intercept all signaling traffic between a caller and a callee and can break a call at any time. Am I right?

    If peers is not responding after a unintended bye, this is a bug in peers. Did peers send the BYE 200 response correctly?

     

  • Anonymous
    2012-05-05

    For your information, a sip proxy NEVER sends a bye request of its own after a call has been established. I guess you are trying to implement a b2bua which can intercept all signaling traffic between a caller and a callee and can break a call at any time. Am I right?

    I think you are. What I have is a web page connected to a SIP Servlet (my registrar app). SIP user agents can register on that server and their SIP URIs show on the web page to click. Clicking sets up a call between two user agents by first calling one and then the other.
    Another link can hang up the call between the agents.
    I need the registration to know which UA's are out there. My registrar app originated from mobicent's click2call demo. I'm not sure in how far it's a full proxy. Apparently it isn't.

    I have got the calling part working.
    Hanging up is the reverse. That part had a bug in my server that I fixed, but what it did is send a BYE to peers for a session that is not (or no longer) open.

    Here is some logging from my server. I hope it comes out allright on this forum.
    It shows Peers running on port 5060 (not registered, no proxy declared), registrar/proxy on 0.0.0.0:5080 (catch-all), and X-Lite running on port 61046 (registered, no proxy).

    CallIds: [e16e0961cc0e506fYzQyYjAyZjU4ZTYyZTBmNGNjZmY0NTcwNjIwYWM5ZGI.]
    #  Time          Delay (ms) pc-durandal:61046                          0.0.0.0:5080
    -----------------------------------------------------------------------------------
    1  22:41:10.000  0                |(a)---REGISTER sip:nist.gov SIP/2.0---->|
    2  22:41:10.012  12               |<-----------SIP/2.0 200 OK-----------(a)|
    ***** vr, 4 mei 2012 22:41:15 845************************************************************
    B2B Tokens: []
    CallIds: [f858f30483f8f06d35692e512db52508@0.0.0.0]
    #   Time          Delay (ms) pc-durandal:5080                  0.0.0.0:5080                                         pc-durandal:61046
    -------------------------------------------------------------------------------------------------------------------------------------
    1   22:41:15.845  0                |                               |(a)------INVITE sip:alice@192.168.2.100:61046-------->|
    2   22:41:15.952  107              |                               |<----------------SIP/2.0 180 Ringing---------------(a)|
    3   22:41:15.959  114              |                               |<------------------SIP/2.0 200 OK------------------(a)|
    4   22:41:16.557  712              |                               |<------------------SIP/2.0 200 OK------------------(a)|
    5   22:41:17.561  1716             |                               |<------------------SIP/2.0 200 OK------------------(a)|
    6   22:41:19.275  3430             |                               |(a)--------ACK sip:alice@192.168.2.100:61046--------->|
    7   22:41:25.629  9784             |                               |(a)--------BYE sip:alice@192.168.2.100:61046--------->|
    8   22:41:25.637  9792             |                               |(a)--------BYE sip:alice@192.168.2.100:61046--------->|
    9   22:41:25.642  9797             |                               |<------------------SIP/2.0 200 OK------------------(a)|
    10  22:41:25.645  9800             |                               |<----SIP/2.0 481 Call/Transaction Does Not Exist---(a)|
    ***** vr, 4 mei 2012 22:41:15 969************************************************************
    B2B Tokens: []
    CallIds: [cf1c09c148e9dbaccea22b3713e3a454@0.0.0.0]
    #   Time          Delay (ms) pc-durandal:5080                  0.0.0.0:5080                                            pc-durandal:5060
    ---------------------------------------------------------------------------------------------------------------------------------------
    1   22:41:15.969  0                |                               |(a)---INVITE sip:operator@192.168.2.100:5060 SIP/2.0---->|
    2   22:41:15.986  17               |                               |<-----------------SIP/2.0 180 Ringing-----------------(a)|
    3   22:41:19.264  3295             |                               |<--------------------SIP/2.0 200 OK-------------------(a)|
    4   22:41:19.279  3310             |                               |(a)-------------ACK sip:192.168.2.100:5060-------------->|
    5   22:41:25.633  9664             |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    6   22:41:25.641  9672             |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    7   22:41:26.133  10164            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    8   22:41:26.142  10173            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    9   22:41:27.133  11164            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    10  22:41:27.142  11173            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    11  22:41:29.133  13164            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    12  22:41:29.142  13173            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    13  22:41:33.133  17164            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    14  22:41:33.142  17173            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    15  22:41:37.134  21165            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    16  22:41:37.142  21173            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    17  22:41:41.134  25165            |                               |(a)-------------BYE sip:192.168.2.100:5060-------------->|
    

    What you can see is while peers and x-lite get a second (or more) BYE, x-lite responds with an OK and an error reply, while peers does nothing (and apparently shuts down, see exception further on).

    I sadly can't reproduce the peers transaction log as I deleted it and fixed the bug (quite a bit of code rewrite) but it i remember it looked ok up to two recieved BYEs, which were the last two messages in the log. No OK reply.

    When peers recieves the BYE for the unknown call it throws this

    Exception in thread "Thread-6" java.lang.IllegalStateException
            at net.sourceforge.peers.sip.transactionuser.DialogStateTerminated.receivedOrSentBye(DialogStateTerminated.java:51)
            at net.sourceforge.peers.sip.transactionuser.Dialog.receivedOrSentBye(Dialog.java:93)
            at net.sourceforge.peers.sip.core.useragent.handlers.ByeHandler.handleBye(ByeHandler.java:75)
            at net.sourceforge.peers.sip.core.useragent.MidDialogRequestManager.manageMidDialogRequest(MidDialogRequestManager.java:194)
            at net.sourceforge.peers.sip.core.useragent.UAS.requestReceived(UAS.java:103)
            at net.sourceforge.peers.sip.core.useragent.UAS.messageReceived(UAS.java:76)
            at net.sourceforge.peers.sip.transport.MessageReceiver.processMessage(MessageReceiver.java:168)
            at net.sourceforge.peers.sip.transport.UdpMessageReceiver.listen(UdpMessageReceiver.java:60)
            at net.sourceforge.peers.sip.transport.MessageReceiver.run(MessageReceiver.java:69)
            at java.lang.Thread.run(Thread.java:722)
    

    After that, no calls are accepted. No INVITE events triggered. Does this give sufficient info?

    If peers is not responding after a unintended bye, this is a bug in peers. Did peers send the BYE 200 response correctly?

    I do think that's a bug yes (no 200 OK), since I expect it to be robust, but I'll leave it to you to decide.

    So you have your custom registrar on a sip node and a custom sip proxy on another node?

    Like I mentioned, it's the same application. I use it for registration and I don't know in how far its proxy functionality is there. I'm still in the learning stage, SIP-wise ;)

    registration issue
    just use the ip address or fqdn of your custom registrar in domain field in peers.xml and let outboundProxy empty.

    Do you mean that that should have peers register without using a proxy?
    i.e. if i set domain to 192.168.2.100:5080 (my registrar IP&Port) and set a password. I'll try, ty.

    As for the logger, it will either run alone or in a web page, and I don't know on which platform. I can only count on std out. No file system. I've made another Config but it leaves the logger. Could you put the logger behind an interface, or make its methods non-final so I can override? If at all possible I don't want to make my own fork of peers-api for future maintainability.

     

  • Anonymous
    2012-05-05

    Oh one more thing.
    In the api, new UserAgent() sets up a user agent with a listener and somewhere in there it creates a Timer thread.
    It looks like timer keeps running, prohibiting the demo app from shutting down gracefully (main thread shuts down, but the timer keeps the app running). I have tried userAgent.close() but that does not end the thread. Should I do something else to shut down the UserAgent?

     
  • maybe you'll have to use 5060 port to reach your custom mobicents proxy/registrar in domain name field in peers.xml.