First of all, I have to say that I really appreciated to work with this application. However, in my environment some issues occurred, which I wanted to report.
If the username and the public id aren't the same (or only the phone number is accepted as public id) the registration fails, because there is no way to specify those attributes separately
Using the softphone in Linux can create some troubles because of the entry 127.0.1.1 in the hosts file. Can be solved by using NetworkInterface.getNetworkInterfaces()
When starting a second call after finishing the first, the started call will ignore the message 407 on terminating and the call will stay open. This is caused by the checked attribute in the ByeHandler, it's not reset on successful response.
Doesn't happen often, but in some cases (InviteHandler received a error response or does reject the call) the RTP DatagramSockt is set null, but not closed. If there is a call received before the natural timeout of the Socket, an BindException will be thrown. I don't know why, but after this there are no messages received after this, so that every request times out.
And a last thing: That one was really tricky. I registered, that the server I had to communicate with, sometimes didn't accept an answer to a 407 401 Message and sent a new challenge. These were often grouped. After examinations of the packages I noticed that all rejected responses to a 407 or a 401 had a hexadecimal value in nc. I focused on this and found the following sentence in the RFC 3261 Documentation "Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication) force hex alphas to be lower case." (Page 164). And after making the nc lowercase, it worked properly.
Huo
Last edit: Huo 2013-11-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
is there a reinvite at the end of distortion?
you can check using wireshark http://www.wireshark.org/ network capture
tool.
Then you can filter traffic using "sip or rtp" filter.
No, there is no re-invite at the end of distortion but some option msgs.. I've used three systems running CentOS 6.5 and each shows the same behaviour. But other interesting behavious it sometime shows is delay but in this case there is no voice distortion. I filtered rtp packets on wirshark and played it, there voice was perfect. so there is no problem in network, pbx or anyother. Here is the log of last call..
when you replay captured rtp packets in wireshark, maybe packets are not
played real-time. Thus, even if the voice is okay in this case, it doesn't
prove that they are sent with the right interval. Rtp packets should be
sent approximatively every 20 ms if I remember correctly. You can check
that in wireshark capture in "Time" field.
Can you send me the capture file? (yohann.martineau gmail)
No, there is no re-invite at the end of distortion but some option msgs..
I've used three systems running CentOS 6.5 and each shows the same
behaviour. But other interesting behavious it sometime shows is delay but
in this case there is no voice distortion. I filtered rtp packets on
wirshark and played it, there voice was perfect. so there is no problem in
network, pbx or anyother. Here is the log of last call..
Hi
First of all, I have to say that I really appreciated to work with this application. However, in my environment some issues occurred, which I wanted to report.
Huo
Last edit: Huo 2013-11-18
Can you further explain local host issue because i'm facing problem of first ten second distortion in linux which is not an issue in windows.
is there a reinvite at the end of distortion?
you can check using wireshark http://www.wireshark.org/ network capture
tool.
Then you can filter traffic using "sip or rtp" filter.
On Fri, Jul 4, 2014 at 5:28 AM, aassh aassh@users.sf.net wrote:
No, there is no re-invite at the end of distortion but some option msgs.. I've used three systems running CentOS 6.5 and each shows the same behaviour. But other interesting behavious it sometime shows is delay but in this case there is no voice distortion. I filtered rtp packets on wirshark and played it, there voice was perfect. so there is no problem in network, pbx or anyother. Here is the log of last call..
//////////////////////////////////////////////////////////////////////
INVITE sip:111111@192.168.178.18:51323;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.178.15:5060;branch=z9hG4bK6135783e;rport
Max-Forwards: 70
From: "zoiperUser" sip:222205@192.168.178.15;tag=as04eede04
To: sip:111111@192.168.178.18:51323;transport=UDP
Contact: sip:222205@192.168.178.15:5060
Call-ID: 5718f9ef46617af07bdddf590c81801e@192.168.178.15:5060
CSeq: 102 INVITE
User-Agent: FPBX-2.11.0(11.10.2)
Date: Thu, 10 Jul 2014 03:46:04 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
P-Asserted-Identity: "zoiperUser" sip:222205@192.168.178.15
Content-Type: application/sdp
Content-Length: 287
v=0
o=root 1110713149 1110713149 IN IP4 192.168.178.15
s=Asterisk PBX 11.10.2
c=IN IP4 192.168.178.15
t=0 0
m=audio 12828 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
2014-07-10 08:46:00,152 DEBUG [TransportManager 0] SM z9hG4bK6135783e|INVITE [InviteServerTransactionStateInit -> InviteServerTransactionStateProceeding] setState
2014-07-10 08:46:00,152 DEBUG [TransportManager 0] SM z9hG4bK6135783e|INVITE [InviteServerTransactionStateProceeding -> InviteServerTransactionStateProceeding] setState
2014-07-10 08:46:00,152 DEBUG [TransportManager 0] SM z9hG4bK6135783e|INVITE [InviteServerTransactionStateProceeding -> InviteServerTransactionStateProceeding] setState
2014-07-10 08:46:00,153 DEBUG [TransportManager 0] UdpMessageSender.sendMessage
2014-07-10 08:46:00,153 DEBUG [TransportManager 0] UdpMessageSender.sendBytes
2014-07-10 08:46:00,153 DEBUG [TransportManager 0] UdpMessageSender.sendBytes 358 /192.168.178.15:5060
2014-07-10 08:46:00,153 DEBUG [TransportManager 0] /192.168.178.18
2014-07-10 08:46:00,153 DEBUG [TransportManager 0] UdpMessageSender.sendBytes packet sent
2014-07-10 08:46:00,153 SENT to 192.168.178.15/5060 [TransportManager 0]
SIP/2.0 180 Ringing
From: "zoiperUser" sip:222205@192.168.178.15;tag=as04eede04
Call-ID: 5718f9ef46617af07bdddf590c81801e@192.168.178.15:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 192.168.178.15:5060;rport=5060;branch=z9hG4bK6135783e
To: sip:111111@192.168.178.18:51323;transport=UDP;tag=CzrgpjTyyc
Contact: <sip:192.168.178.18:51323;transport=udp></sip:192.168.178.18:51323;transport=udp>
2014-07-10 08:46:00,154 DEBUG [TransportManager 0] SM 5718f9ef46617af07bdddf590c81801e@192.168.178.15:5060|as04eede04|CzrgpjTyyc [DialogStateInit -> DialogStateEarly] setState
2014-07-10 08:46:00,185 DEBUG [AWT-EventQueue-0] SM 5718f9ef46617af07bdddf590c81801e@192.168.178.15:5060 [CallFrameStateInit -> CallFrameStateUas] setState
2014-07-10 08:46:00,366 DEBUG [TransactionManager Timer] SM z9hG4bKpxY8742me|REGISTER [NonInviteClientTransactionStateCompleted -> NonInviteClientTransactionStateTerminated] setState
2014-07-10 08:46:00,533 DEBUG [TransactionManager Timer] SM z9hG4bKOn87Vd7hB|REGISTER [NonInviteClientTransactionStateCompleted -> NonInviteClientTransactionStateTerminated] setState
2014-07-10 08:46:02,435 DEBUG [AWT-EventQueue-0] SM 5718f9ef46617af07bdddf590c81801e@192.168.178.15:5060 [CallFrameStateUas -> CallFrameStateSuccess] setState
2014-07-10 08:46:02,473 DEBUG [AWT-EventQueue-0] new rtp DatagramSocket 1107571654
2014-07-10 08:46:02,477 DEBUG [AWT-EventQueue-0] SM z9hG4bK6135783e|INVITE [InviteServerTransactionStateProceeding -> InviteServerTransactionStateProceeding] setState
2014-07-10 08:46:02,477 DEBUG [AWT-EventQueue-0] SM z9hG4bK6135783e|INVITE [InviteServerTransactionStateProceeding -> InviteServerTransactionStateTerminated] setState
2014-07-10 08:46:02,477 DEBUG [AWT-EventQueue-0] UdpMessageSender.sendMessage
2014-07-10 08:46:02,477 DEBUG [AWT-EventQueue-0] UdpMessageSender.sendBytes
2014-07-10 08:46:02,477 DEBUG [AWT-EventQueue-0] UdpMessageSender.sendBytes 622 /192.168.178.15:5060
2014-07-10 08:46:02,478 DEBUG [AWT-EventQueue-0] /192.168.178.18
2014-07-10 08:46:02,478 DEBUG [AWT-EventQueue-0] UdpMessageSender.sendBytes packet sent
2014-07-10 08:46:02,478 SENT to 192.168.178.15/5060 [AWT-EventQueue-0]
SIP/2.0 200 OK
From: "zoiperUser" sip:222205@192.168.178.15;tag=as04eede04
Call-ID: 5718f9ef46617af07bdddf590c81801e@192.168.178.15:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 192.168.178.15:5060;rport=5060;branch=z9hG4bK6135783e
To: sip:111111@192.168.178.18:51323;transport=UDP;tag=CzrgpjTyyc
Content-Length: 217
Content-Type: application/sdp
Contact: <sip:192.168.178.18:51323;transport=udp></sip:192.168.178.18:51323;transport=udp>
v=0
o=user1 1120745503 1305125956 IN IP4 192.168.178.18
s=-
c=IN IP4 192.168.178.18
t=0 0
m=audio 59234 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
2014-07-10 08:46:02,478 DEBUG [AWT-EventQueue-0] SM 5718f9ef46617af07bdddf590c81801e@192.168.178.15:5060|as04eede04|CzrgpjTyyc [DialogStateEarly -> DialogStateConfirmed] setState
2014-07-10 08:46:02,479 RECEIVED from 192.168.178.15/5060 [TransportManager 0]
ACK sip:192.168.178.18:51323;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.178.15:5060;branch=z9hG4bK68608dd5;rport
Max-Forwards: 70
From: "zoiperUser" sip:222205@192.168.178.15;tag=as04eede04
To: sip:111111@192.168.178.18:51323;transport=UDP;tag=CzrgpjTyyc
Contact: sip:222205@192.168.178.15:5060
Call-ID: 5718f9ef46617af07bdddf590c81801e@192.168.178.15:5060
CSeq: 102 ACK
User-Agent: FPBX-2.11.0(11.10.2)
Content-Length: 0
2014-07-10 08:46:02,480 DEBUG [TransportManager 0] handleAck
2014-07-10 08:46:02,481 DEBUG [TransportManager 0] openAndStartLines
2014-07-10 08:46:02,629 DEBUG [TransportManager 0] playback codec:a=rtpmap:0 PCMU/8000
2014-07-10 08:46:20,367 DEBUG [UdpMessageSender Timer] UdpMessageSender.sendBytes
2014-07-10 08:46:20,367 DEBUG [UdpMessageSender Timer] UdpMessageSender.sendBytes 4 /192.168.178.15:5060
2014-07-10 08:46:20,367 DEBUG [UdpMessageSender Timer] /192.168.178.18
2014-07-10 08:46:20,367 DEBUG [UdpMessageSender Timer] UdpMessageSender.sendBytes packet sent
2014-07-10 08:46:45,367 DEBUG [UdpMessageSender Timer] UdpMessageSender.sendBytes
2014-07-10 08:46:45,367 DEBUG [UdpMessageSender Timer] UdpMessageSender.sendBytes 4 /192.168.178.15:5060
2014-07-10 08:46:45,367 DEBUG [UdpMessageSender Timer] /192.168.178.18
2014-07-10 08:46:45,367 DEBUG [UdpMessageSender Timer] UdpMessageSender.sendBytes packet sent
2014-07-10 08:46:56,558 RECEIVED from 192.168.178.15/5060 [TransportManager 0]
//////////////////////////////////////////////////////////////////////////
////////somewhere at this point distortion ends///////////////////////////
OPTIONS sip:111111@192.168.178.18:51323;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.178.15:5060;branch=z9hG4bK5916ac2f;rport
Max-Forwards: 70
From: "Unknown" sip:Unknown@192.168.178.15;tag=as3fec59ca
To: sip:111111@192.168.178.18:51323;transport=UDP
Contact: sip:Unknown@192.168.178.15:5060
Call-ID: 5960a5301a18d3de7a6022073617ca4d@192.168.178.15:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-2.11.0(11.10.2)
Date: Thu, 10 Jul 2014 03:47:00 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
2014-07-10 08:46:56,560 DEBUG [TransportManager 0] SM z9hG4bK5916ac2f|OPTIONS [NonInviteServerTransactionStateTrying -> NonInviteServerTransactionStateCompleted] setState
2014-07-10 08:46:57,557 RECEIVED from 192.168.178.15/5060 [TransportManager 0]
OPTIONS sip:111111@192.168.178.18:51323;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.178.15:5060;branch=z9hG4bK5916ac2f;rport
Max-Forwards: 70
From: "Unknown" sip:Unknown@192.168.178.15;tag=as3fec59ca
To: sip:111111@192.168.178.18:51323;transport=UDP
Contact: sip:Unknown@192.168.178.15:5060
Call-ID: 5960a5301a18d3de7a6022073617ca4d@192.168.178.15:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-2.11.0(11.10.2)
Date: Thu, 10 Jul 2014 03:47:00 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
2014-07-10 08:46:57,559 DEBUG [TransportManager 0] SM z9hG4bK5916ac2f|OPTIONS [NonInviteServerTransactionStateCompleted -> NonInviteServerTransactionStateCompleted] setState
2014-07-10 08:46:57,560 DEBUG [TransportManager 0] UdpMessageSender.sendMessage
2014-07-10 08:46:57,560 DEBUG [TransportManager 0] UdpMessageSender.sendBytes
2014-07-10 08:46:57,560 DEBUG [TransportManager 0] UdpMessageSender.sendBytes 661 /192.168.178.15:5060
2014-07-10 08:46:57,562 DEBUG [TransportManager 0] /192.168.178.18
2014-07-10 08:46:57,562 DEBUG [TransportManager 0] UdpMessageSender.sendBytes packet sent
2014-07-10 08:46:57,562 SENT to 192.168.178.15/5060 [TransportManager 0]
SIP/2.0 200 OK
From: "Unknown" sip:Unknown@192.168.178.15;tag=as3fec59ca
Call-ID: 5960a5301a18d3de7a6022073617ca4d@192.168.178.15:5060
CSeq: 102 OPTIONS
Via: SIP/2.0/UDP 192.168.178.15:5060;rport=5060;branch=z9hG4bK5916ac2f
To: sip:111111@192.168.178.18:51323;transport=UDP;tag=I6n5FRFtuF
Content-Length: 215
Content-Type: application/sdp
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Contact: <sip:192.168.178.18:51323;transport=udp></sip:192.168.178.18:51323;transport=udp>
v=0
o=user1 568090280 550376161 IN IP4 192.168.178.18
s=-
c=IN IP4 192.168.178.18
t=0 0
m=audio 56804 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
2014-07-10 08:47:10,368 DEBUG [UdpMessageSender Timer] UdpMessageSender.sendBytes
2014-07-10 08:47:10,368 DEBUG [UdpMessageSender Timer] UdpMessageSender.sendBytes 4 /192.168.178.15:5060
hi,
when you replay captured rtp packets in wireshark, maybe packets are not
played real-time. Thus, even if the voice is okay in this case, it doesn't
prove that they are sent with the right interval. Rtp packets should be
sent approximatively every 20 ms if I remember correctly. You can check
that in wireshark capture in "Time" field.
Can you send me the capture file? (yohann.martineau gmail)
thanks,
yohann
On Thu, Jul 10, 2014 at 6:02 AM, aassh aassh@users.sf.net wrote: