Auto Video Call Hangup

Home » Asterisk Users » Auto Video Call Hangup
Asterisk Users 1 Comment

Hi,

I use a simple scheme:

SIP video phone A (h264/Asterisk 1.8.11) <---IAX2 trunk----> SIP video phone B (h264/Asterisk 11.7.0)

When calls from A to B and vice versa drop on pickup.

On B side:

[Oct 24 16:33:49] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Setting the marker bit due to a source update
[Oct 24 16:33:49] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Setting the marker bit due to a source update
[Oct 24 16:33:49] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Setting the marker bit due to a source update
[Oct 24 16:33:49] WARNING[15202] chan_iax2.c: Received mini frame before first full video frame
[Oct 24 16:33:49] DEBUG[15206] chan_iax2.c: Ooh, video format changed to h264
[Oct 24 16:33:49] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Ooh, format changed from unknown to h264
[Oct 24 16:33:49] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Starting RTCP transmission on RTP instance ‘0xb7d79c54’
[Oct 24 16:33:49] DEBUG[15207] chan_iax2.c: Ooh, voice format changed to
‘ulaw’
[Oct 24 16:33:49] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Ooh, format changed from unknown to ulaw
[Oct 24 16:33:49] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Created smoother: format: ulaw ms: 20 len: 160
[Oct 24 16:33:49] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Starting RTCP transmission on RTP instance ‘0xb69b9894’
[Oct 24 16:33:49] DEBUG[15204] chan_iax2.c: Packet arrived out of order
(expecting 7, got 5) (frametype = 3, subclass = 200004)
[Oct 24 16:33:49] DEBUG[15204] chan_iax2.c: Acking anyway
[Oct 24 16:33:49] DEBUG[15211] chan_iax2.c: Packet arrived out of order
(expecting 7, got 6) (frametype = 2, subclass = 100003)
[Oct 24 16:33:49] DEBUG[15211] chan_iax2.c: Acking anyway
[Oct 24 16:33:49] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Difference is 45450, ms is 505 (45450), pred/ts/samples 45450/0/0
[Oct 24 16:33:50] DEBUG[15193][C-00000012] chan_sip.c: Trying to put
‘SIP/2.0 200’ onto UDP socket destined for 192.168.0.192:5060
[Oct 24 16:33:50] DEBUG[15590][C-00000012] res_rtp_asterisk.c: 0xb7d93ce0
— Probation learning mode pass with source address 192.168.0.192:5004
[Oct 24 16:33:50] DEBUG[15590][C-00000012] res_rtp_asterisk.c: 0xb69b5488
— Probation learning mode pass with source address 192.168.0.192:5006
[Oct 24 16:33:50] WARNING[15590][C-00000012] chan_iax2.c: Can’t compress subclass 2097217
[Oct 24 16:33:50] DEBUG[15207] chan_iax2.c: Received VNAK: resending outstanding frames
[Oct 24 16:33:50] DEBUG[15209] chan_iax2.c: Received VNAK: resending outstanding frames
[Oct 24 16:33:50] DEBUG[15208] chan_iax2.c: Received VNAK: resending outstanding frames
[Oct 24 16:33:50] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Setting the marker bit due to a source update
[Oct 24 16:33:50] DEBUG[15204] chan_iax2.c: Received VNAK: resending outstanding frames
[Oct 24 16:33:50] DEBUG[15211] chan_iax2.c: Received VNAK: resending outstanding frames
[Oct 24 16:33:50] DEBUG[15203] chan_iax2.c: Received VNAK: resending outstanding frames
[Oct 24 16:33:50] DEBUG[15202] chan_iax2.c: Received VNAK: resending outstanding frames
[Oct 24 16:33:50] DEBUG[15206] chan_iax2.c: Received VNAK: resending outstanding frames
[Oct 24 16:33:50] DEBUG[15205] chan_iax2.c: Immediately destroying 1664, having received hangup
[Oct 24 16:33:50] DEBUG[15227] manager.c: Examining event:
[Oct 24 16:33:50] DEBUG[15590][C-00000012] channel.c: Didn’t get a frame from channel: IAX2/THNS-1664
[Oct 24 16:33:50] DEBUG[15590][C-00000012] res_rtp_asterisk.c: Setting the marker bit due to a source update
[Oct 24 16:33:50] DEBUG[15590][C-00000012] channel.c: Bridge stops bridging channels IAX2/THNS-1664 and SIP/507-0000001d
[Oct 24 16:33:50] DEBUG[15590][C-00000012] channel.c: Soft-Hanging up channel ‘IAX2/THNS-1664’
[Oct 24 16:33:50] DEBUG[15590][C-00000012] pbx.c: Launching ‘Macro’
[Oct 24 16:33:50] VERBOSE[15590][C-00000012] pbx.c: — Executing
[h@macro-dial-one:1] Macro(“IAX2/THNS-1664”, “hangupcall,”) in new stack

Debug at A side:

[Oct 23 17:42:47] WARNING[14880] chan_iax2.c: Received mini frame before first full video frame
[Oct 23 17:42:47] WARNING[14887] chan_iax2.c: Received mini frame before first full video frame
[Oct 23 17:42:47] WARNING[14881] chan_iax2.c: Received mini frame before first full video frame
[Oct 23 17:42:47] WARNING[14885] chan_iax2.c: Received mini frame before first full video frame
[Oct 23 17:42:47] WARNING[22489] res_rtp_asterisk.c: Don’t know how to send format unknown packets with RTP
[Oct 23 17:42:47] WARNING[14886] chan_iax2.c: Received mini frame before first full video frame
[Oct 23 17:42:47] WARNING[14879] chan_iax2.c: Received mini frame before first full video frame
[Oct 23 17:42:47] WARNING[14878] chan_iax2.c: Received mini frame before first full video frame
[Oct 23 17:42:47] WARNING[14880] chan_iax2.c: Received mini frame before first full video frame
[Oct 23 17:42:47] WARNING[14887] chan_iax2.c: Received mini frame before first full video frame
[Oct 23 17:42:47] WARNING[14881] chan_iax2.c: Received mini frame before first full video frame
[Oct 23 17:42:47] VERBOSE[22489] pbx.c: — Executing
[h@macro-dialout-trunk:1] Macro(“SIP/102-00000098”, “hangupcall,”) in new stack

I have also tested with the following setup and video is displayed correctly (the only difference is the asterisk version of B)

SIP video phone A (h264/Asterisk 1.8.11) <---IAX2 trunk----> SIP video phone B (h264/Asterisk 1.8.20)

Any pointers to help me debug further please? Does had a similar problem?
The videophones used A:Grandstream GXV-3000/3140 B:Grandstream GXV-3275

Thanks

One thought on - Auto Video Call Hangup

  • Markos Vakondios gmail.com> writes:

    phone B (h264/Asterisk 11.7.0)
    the marker bit due to a source update the marker bit due to a source update the marker bit due to a source update before first full video frame to h264
    format changed from unknown to h264
    Starting RTCP transmission on RTP instance ‘0xb7d79c54’
    to ‘ulaw’
    format changed from unknown to ulaw smoother: format: ulaw ms: 20 len: 160
    Starting RTCP transmission on RTP instance ‘0xb69b9894’
    order (expecting 7, got 5) (frametype = 3, subclass = 200004)
    order (expecting 7, got 6) (frametype = 2, subclass = 100003)
    Difference is 45450, ms is 505 (45450), pred/ts/samples 45450/0/0
    ‘SIP/2.0 200’ onto UDP socket destined for 192.168.0.192:5060
    0xb7d93ce0 — Probation learning mode pass with source address 192.168.0.192:5004
    0xb69b5488 — Probation learning mode pass with source address 192.168.0.192:5006
    compress subclass 2097217
    outstanding frames outstanding frames outstanding frames the marker bit due to a source update outstanding frames outstanding frames outstanding frames outstanding frames outstanding frames
    1664, having received hangup frame from channel: IAX2/THNS-1664
    the marker bit due to a source update bridging channels IAX2/THNS-1664 and SIP/507-0000001d channel ‘IAX2/THNS-1664’
    [h macro-dial-one:1] Macro(“IAX2/THNS-1664”, “hangupcall,”) in new stack before first full video frame before first full video frame before first full video frame before first full video frame send format unknown packets with RTP
    before first full video frame before first full video frame before first full video frame before first full video frame before first full video frame before first full video frame macro-dialout-trunk:1] Macro(“SIP/102-00000098”, “hangupcall,”) in new stack correctly (the only difference is the asterisk version of B)
    phone B (h264/Asterisk 1.8.20)
    problem? The videophones used A:Grandstream GXV-3000/3140 B:Grandstream GXV-3275

    Hi

    Did you ever find a solution to this problem?
    I am having the same issue.

    Thanks