stun_msg.c Unrecognized attribute type 0x8020
On Thu, Jul 10, 2008 at 1:26 PM, Will Davies will@hugthebubble.co.uk
wrote:
Hi,
I'm trying to get pjsua-0.9.0 working on puppylinux.
Some people are reporting that all their calls drop out after a few
minutes.
We have set
--use-ice
--stun-srv=stun01.sipphone.com
we have gizmo accounts.
The only common factor between users with dropped calls seems to be that
they have dynamic internet addresses. Please could anyone tell me if the
line from stun_msg.c below could be related to this problem.
That should be okay, that STUN attribute is optional. Are you sure it's
pjsip that's dropping the call and not Gizmo?
Cheers
Benny
many thanks
Will Davies
10:40:24.095 stun_msg.c Unrecognized attribute type 0x8020
10:40:24.095 stuntp0x81cb51 RX 88 bytes STUN message from
69.0.208.27:3478:
--- begin STUN message ---
STUN Binding success response
Hdr: length=68, magic=2112a442, tsx_id=f47fff3eb440aa65000253b3
Attributes:
MAPPED-ADDRESS: length=8, IPv4 addr=my-ip:32807
SOURCE-ADDRESS: length=8, IPv4 addr=69.0.208.27:3478
CHANGED-ADDRESS: length=8, IPv4 addr=69.0.209.22:3479
???: length=8
SERVER: length=16, value="Vovida.org 0.96"
--- end of STUN message ---
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
On Thu, Jul 10, 2008 at 2:42 PM, Will Davies will@hugthebubble.co.uk
wrote:
That should be okay, that STUN attribute is optional. Are you sure it's
pjsip that's dropping the call and not Gizmo?
thanks for the response
That would seem unlikely, how would I tell?
users A, B, C and D all have gizmo accounts
users A and B can hold a conversation for over 40 minutes
any call involving users C or D generally dies after 6-10 minutes (maximum
so far 12)
users A and B have static internet addresses
users C and D have dynamic internet addresses
Its not much as far as proof goes. I'm slightly overwhelmed by the
verbosity of the log and in over my head. Any pointers on things to look for
would be gratefully received.
Yeah I know what you mean about the log. But look for the part where BYE
message is sent or received, and see who sends it. If the sender is pjsip,
scan few lines before that, normally it should print out why it hangs up the
call (unless of course if it's user who hangs up the call).
The other point to note is that users C and D see very high cpu utilisation
when the call dies.
Okay that's interesting. If the CPU utilization is very very high, then it
could cause some SIP transactions to timeout with 408 status, and this
status will terminate the call indeed. But I don't think this would happen
unless the CPU utilization is very very high (to the point that the computer
feels like it's locked up).
Cheers
Benny
Will Davies
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Hi,
I'm trying to get pjsua-0.9.0 working on puppylinux.
Some people are reporting that all their calls drop out after a few minutes.
We have set
--use-ice
--stun-srv=stun01.sipphone.com
we have gizmo accounts.
The only common factor between users with dropped calls seems to be that they have dynamic internet addresses. Please could anyone tell me if the line from stun_msg.c below could be related to this problem.
many thanks
Will Davies
10:40:24.095 stun_msg.c Unrecognized attribute type 0x8020
10:40:24.095 stuntp0x81cb51 RX 88 bytes STUN message from 69.0.208.27:3478:
--- begin STUN message ---
STUN Binding success response
Hdr: length=68, magic=2112a442, tsx_id=f47fff3eb440aa65000253b3
Attributes:
MAPPED-ADDRESS: length=8, IPv4 addr=my-ip:32807
SOURCE-ADDRESS: length=8, IPv4 addr=69.0.208.27:3478
CHANGED-ADDRESS: length=8, IPv4 addr=69.0.209.22:3479
???: length=8
SERVER: length=16, value="Vovida.org 0.96"
--- end of STUN message ---
On Thu, 10 Jul 2008 12:26:51 +0100
"Benny Prijono" bennylp@pjsip.org wrote:
On Thu, Jul 10, 2008 at 1:26 PM, Will Davies will@hugthebubble.co.uk
wrote:
Hi,
I'm trying to get pjsua-0.9.0 working on puppylinux.
Some people are reporting that all their calls drop out after a few
minutes.
We have set
--use-ice
--stun-srv=stun01.sipphone.com
we have gizmo accounts.
The only common factor between users with dropped calls seems to be that
they have dynamic internet addresses. Please could anyone tell me if the
line from stun_msg.c below could be related to this problem.
That should be okay, that STUN attribute is optional. Are you sure it's
pjsip that's dropping the call and not Gizmo?
thanks for the response
That would seem unlikely, how would I tell?
users A, B, C and D all have gizmo accounts
users A and B can hold a conversation for over 40 minutes
any call involving users C or D generally dies after 6-10 minutes (maximum so far 12)
users A and B have static internet addresses
users C and D have dynamic internet addresses
Its not much as far as proof goes. I'm slightly overwhelmed by the verbosity of the log and in over my head. Any pointers on things to look for would be gratefully received.
The other point to note is that users C and D see very high cpu utilisation when the call dies.
Will Davies
On Thu, 10 Jul 2008 12:57:16 +0100
"Benny Prijono" bennylp@pjsip.org wrote:
On Thu, Jul 10, 2008 at 2:42 PM, Will Davies will@hugthebubble.co.uk
wrote:
That should be okay, that STUN attribute is optional. Are you sure it's
pjsip that's dropping the call and not Gizmo?
thanks for the response
That would seem unlikely, how would I tell?
users A, B, C and D all have gizmo accounts
users A and B can hold a conversation for over 40 minutes
any call involving users C or D generally dies after 6-10 minutes (maximum
so far 12)
users A and B have static internet addresses
users C and D have dynamic internet addresses
Its not much as far as proof goes. I'm slightly overwhelmed by the
verbosity of the log and in over my head. Any pointers on things to look for
would be gratefully received.
Yeah I know what you mean about the log. But look for the part where BYE
message is sent or received, and see who sends it. If the sender is pjsip,
scan few lines before that, normally it should print out why it hangs up the
call (unless of course if it's user who hangs up the call).
There is no BYE until one of us hangs up. I have a log that include several minutes after the sound stopped. The only think I have managed to learn from it is that the
18:37:45.594 strm0x823ce04 Starting silence
18:37:45.595 strm0x823ce04 Start talksprut..
messages on the machine with the high cpu utilisation stop at the same time that the call stops working.
I continue to get these messages at the other end but neither of us can hear anything
The other point to note is that users C and D see very high cpu utilisation
when the call dies.
Okay that's interesting. If the CPU utilization is very very high, then it
could cause some SIP transactions to timeout with 408 status, and this
status will terminate the call indeed. But I don't think this would happen
unless the CPU utilization is very very high (to the point that the computer
feels like it's locked up).
No 408s in the log
thanks
Will Davies
On Fri, Jul 11, 2008 at 1:21 PM, Will Davies will@hugthebubble.co.uk
wrote:
Yeah I know what you mean about the log. But look for the part where BYE
message is sent or received, and see who sends it. If the sender is
pjsip,
scan few lines before that, normally it should print out why it hangs up
the
call (unless of course if it's user who hangs up the call).
There is no BYE until one of us hangs up. I have a log that include several
minutes after the sound stopped. The only think I have managed to learn from
it is that the
18:37:45.594 strm0x823ce04 Starting silence
18:37:45.595 strm0x823ce04 Start talksprut..
messages on the machine with the high cpu utilisation stop at the same time
that the call stops working.
I continue to get these messages at the other end but neither of us can
hear anything
That should be fine. These messages are just to report that the VAD is
kicking in.
So this is not a call drop in the usual sense then since signaling seems to
be still in place (calls are still CONFIRMED on both ends), but rather lost
of audio after few minutes of conversation. Is that right?
In that case then these links will probably help:
http://trac.pjsip.org/repos/wiki/audio-problem-local-no-audio
http://trac.pjsip.org/repos/wiki/audio-problem-remote-no-audio
Cheers
Benny
On Mon, Jul 14, 2008 at 1:39 PM, Will Davies will@hugthebubble.co.uk
wrote:
On Fri, 11 Jul 2008 16:33:59 +0100
"Benny Prijono" bennylp@pjsip.org wrote:
So this is not a call drop in the usual sense then since signaling seems
to
be still in place (calls are still CONFIRMED on both ends), but rather
lost
of audio after few minutes of conversation. Is that right?
I have a couple of logs from this user's machine where calls never to the
CONFIRMED state, but we had a conversation that lasted over a minute. I
would blame gizmo but there are other users for which it works fine.
In that case then these links will probably help:
http://trac.pjsip.org/repos/wiki/audio-problem-local-no-audio
http://trac.pjsip.org/repos/wiki/audio-problem-remote-no-audio
considering that the audio works to start with
are there any particular candidates there which might take a while for the
problem to kick in.
http://trac.pjsip.org/repos/wiki/audio-check-rx-rtp is probably interesting.
When the audio stalls, it would be good to see if RTP packets are still
sent/received (the number of RTP packets sent and received are increasing).
Would it be possible that Gizmo changes the codec in the middle of call
without sending re-INVITE or UPDATE? When this happens you'll see loads of
"invalid pt" error in the log though.
Also even though as you said the problematic calls always involve users with
dynamic IP, I assume the IP address doesn't change in the middle of a call,
don't you think?
Apart from these I can't think of anything else for now.
-benny
On Fri, 11 Jul 2008 16:33:59 +0100
"Benny Prijono" bennylp@pjsip.org wrote:
So this is not a call drop in the usual sense then since signaling seems to
be still in place (calls are still CONFIRMED on both ends), but rather lost
of audio after few minutes of conversation. Is that right?
I have a couple of logs from this user's machine where calls never to the CONFIRMED state, but we had a conversation that lasted over a minute. I would blame gizmo but there are other users for which it works fine.
In that case then these links will probably help:
http://trac.pjsip.org/repos/wiki/audio-problem-local-no-audio
http://trac.pjsip.org/repos/wiki/audio-problem-remote-no-audio
considering that the audio works to start with
are there any particular candidates there which might take a while for the problem to kick in.
Will Davies
On Mon, Jul 14, 2008 at 3:47 PM, Will Davies will@hugthebubble.co.uk
wrote:
On Mon, 14 Jul 2008 13:38:24 -0100
Will Davies will@hugthebubble.co.uk wrote:
On Mon, 14 Jul 2008 12:24:57 +0100
"Benny Prijono" bennylp@pjsip.org wrote:
interesting.
When the audio stalls, it would be good to see if RTP packets are still
sent/received (the number of RTP packets sent and received are
increasing).
Bingo
DOH
sorry I was misreading the output, I now realise there is nothing useful
there
Yeah I was about to say that. The log says that you should be talking
happily, and you were talking happily, so there's not much to see there.
:)
Cheers
Benny
On Mon, 14 Jul 2008 12:24:57 +0100
"Benny Prijono" bennylp@pjsip.org wrote:
http://trac.pjsip.org/repos/wiki/audio-check-rx-rtp is probably interesting.
When the audio stalls, it would be good to see if RTP packets are still
sent/received (the number of RTP packets sent and received are increasing).
Bingo
13:14:21.148 pjsua_app.c
[CONFIRMED] To: sip:mybuddy@proxy01.sipphone.com;tag=09d541aa-c45b-46f9-b453-414435bb3a84
Call time: 00h:09m:48s, 1st res in 6604 ms, conn in 6605ms
SRTP status: Not active Crypto-suite: (null)
#0 speex @16KHz, sendrecv, peer=198.65.166.131:47856
RX pt=103, stat last update: 00h:00m:04.161s ago
total 28.6Kpkt 2.96MB (4.10MB +IP hdr) @avg=40.2Kbps/55.8Kbps
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 17.931 156.000 15.312 3.700
TX pt=103, ptime=20ms, stat last update: never
total 23.6Kpkt 1.54MB (2.49MB +IP hdr) @avg 21.0Kbps/33.8Kbps
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 0.000 0.000 0.000 0.000
RTT msec : 0.000 0.000 0.000 0.000 0.000
13:27:43.421 pjsua_app.c
[CONFIRMED] To: sip:mybuddy@proxy01.sipphone.com;tag=09d541aa-c45b-46f9-b453-414435bb3a84
Call time: 00h:23m:10s, 1st res in 6604 ms, conn in 6605ms
SRTP status: Not active Crypto-suite: (null)
#0 speex @16KHz, sendrecv, peer=198.65.166.131:47856
RX pt=103, stat last update: 00h:00m:03.728s ago
total 67.2Kpkt 6.90MB (9.59MB +IP hdr) @avg=39.7Kbps/55.2Kbps
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 18.001 177.000 19.937 3.861
TX pt=103, ptime=20ms, stat last update: never
total 55.8Kpkt 3.62MB (5.86MB +IP hdr) @avg 20.8Kbps/33.7Kbps
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 0.000 0.000 0.000 0.000
RTT msec : 0.000 0.000 0.000 0.000 0.000
We were talking happily all the way through this. Interesting?
We were talking happily all the way through this mybuddy was using a version of pjsua checked out of subversion towards the end of June, I was using 0.9.0. We are not sure exactly what the revision number was of his version. I'm going to use the incredibly unscientific method of going through the repository jumping a couple of days at time. Last test was with 2054, no joy.
--
Will Davies