I don't know what status packet is but, that's right, asterisk closes connection after 30s. Not because ACK is not sent, but because it does not contain Authorization. This is a known bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
32s is an INVITE transaction timer. Call has not been estabilshed successfully, so after 32s INVITE server transaction is terminated and dialog is also terminated sending a BYE to both parties.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The call is established. I'm able to hear as well as transmit voice data during the first 32 seconds. Proper conversations can be carried out for the first 32 seconds.
yes, but even if the call has started, Asterisk does not receive ACK sip request which is mandatory to validate connection. Thus, even if rtp media stream is established between caller and callee, the lack of this ACK message could mean that there's an issue on the caller's side and it closes the call on both sides.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
this is a bug in peers. Neverthless, I think it has been included in version 0.4.1. Could you check that you have the same problem with version 0.4? And could you run a test with version 0.3.1? In this version, you have to edit conf/peers.xml manually to apply your account settings.
Thanks,
yohann
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will test it asap. On a completely unrelated note, I am facing difficulty in making peers into an executable jar. In particular,
Exception in thread "Thread-2" java.lang.NullPointerException
at net.sourceforge.peers.sip.Utils.generateCallID(Utils.java:59)
Have you made an executable jar? What are the steps you took?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry yohann,
Silly me! Was testing the wrong archive. after an ant build, the batch file in peers.zip works perfectly!
Please disregard the above reply!
Anirudh
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
can you send a wireshark pcap capture of this test?
Or can you take a look at ACK, check that it contains an Authorization header, a branchId different from 200 OK response and an Authorization header in BYE if a BYE is sent?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here… I am attaching the wireshark responses I'm getting. All calls are made via asterisk 1.8. 192.168.0.192 is my local asterisk server and 192.168.0.128 is the computer on which I have x-lite as well as peers.
I did not take a snapshot of the hangup part, but the rest is below.
This is xlite calling peers via asterisk.(hangup not shown)
and this is peers calling xlite via asterisk (not showing hangup)
I have also included the wireshark captured pcap files here (please filter by SIP)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This issue is fixed with the trunk version of peers on adding directmedia=no in sip.conf, (it is canreinvite=no, for older versions of asterisk) for all numbers handled by peers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Asterisk 1.8 expects an ack to the Status Packet, atleast every 30s. This causes it to hang up at around 30s.
4140 31.879444 192.168.0.128 192.168.0.192 SIP/SDP Status: 200 OK, with session description
4141 31.880294 192.168.0.192 192.168.0.128 SIP Request: ACK sip:192.168.0.128:6060;transport=UDP
The second ACK packet is not being sent by Peers (tested with 0.4.1 and 0.4)
Asterisk Console :
Hanging up call 5PPaIu5p-1308667904980@localhost - no reply to our critical packet (see doc/sip-retransmit.txt).
I don't know what status packet is but, that's right, asterisk closes connection after 30s. Not because ACK is not sent, but because it does not contain Authorization. This is a known bug.
32s is an INVITE transaction timer. Call has not been estabilshed successfully, so after 32s INVITE server transaction is terminated and dialog is also terminated sending a BYE to both parties.
The call is established. I'm able to hear as well as transmit voice data during the first 32 seconds. Proper conversations can be carried out for the first 32 seconds.
Please see this.
yes, but even if the call has started, Asterisk does not receive ACK sip request which is mandatory to validate connection. Thus, even if rtp media stream is established between caller and callee, the lack of this ACK message could mean that there's an issue on the caller's side and it closes the call on both sides.
Oh… So is this an issue with my Asterisk configuration? Or is it a peers bug?
this is a bug in peers. Neverthless, I think it has been included in version 0.4.1. Could you check that you have the same problem with version 0.4? And could you run a test with version 0.3.1? In this version, you have to edit conf/peers.xml manually to apply your account settings.
Thanks,
yohann
I will test it asap. On a completely unrelated note, I am facing difficulty in making peers into an executable jar. In particular,
Exception in thread "Thread-2" java.lang.NullPointerException
at net.sourceforge.peers.sip.Utils.generateCallID(Utils.java:59)
Have you made an executable jar? What are the steps you took?
Thanks!
Sorry yohann,
Silly me! Was testing the wrong archive. after an ant build, the batch file in peers.zip works perfectly!
Please disregard the above reply!
Anirudh
I fixed an issue in trunk, could you try with latest version from svn?
thanks,
yohann
Just tested with the new trunk build. It still faces the same 32s disconnect issue with asterisk.
Hanging up call xUr4CR0z-1308901760741@anirudh-PC - no reply to our critical packet (see doc/sip-retransmit.txt).
Peers does not detect the call disconnect, It still says "Talking…"
can you send a wireshark pcap capture of this test?
Or can you take a look at ACK, check that it contains an Authorization header, a branchId different from 200 OK response and an Authorization header in BYE if a BYE is sent?
Thanks
Here… I am attaching the wireshark responses I'm getting. All calls are made via asterisk 1.8. 192.168.0.192 is my local asterisk server and 192.168.0.128 is the computer on which I have x-lite as well as peers.
I did not take a snapshot of the hangup part, but the rest is below.
This is xlite calling peers via asterisk.(hangup not shown)
and this is peers calling xlite via asterisk (not showing hangup)
I have also included the wireshark captured pcap files here (please filter by SIP)
This issue is fixed with the trunk version of peers on adding directmedia=no in sip.conf, (it is canreinvite=no, for older versions of asterisk) for all numbers handled by peers.