[Home]

Summary:ASTERISK-19179: RTP inactivity SIP / ooh323 wont work
Reporter:TSAREGORODTSEV Yury (tsarik)Labels:
Date Opened:2012-01-10 17:50:49.000-0600Date Closed:2012-06-19 18:31:20
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Addons/chan_ooh323 Channels/chan_sip/General
Versions:10.0.0 Frequency of
Occurrence
Related
Issues:
Environment:Also same bug in 1.8.8.0, 1.8.8.1, 10.0.0, 10.1.0-r1 versions.Attachments:( 0) 19179-ooh323-2.patch
( 1) 19179-ooh323-ast10.patch
( 2) ASTERISK-19179-1.patch
Description:Asterisk won't to disconnect calls due to rtp inactivity:
when asterisk stop receive incoming OR outgoing RTP packets will not changed during anytime before other party hangup this call.
same situation in both protocols (sip, ooh323).
Its mean if RTP still going in one of directions - asterisk will not disconnect this call.

Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
85.195.000.2     463380552@8  00:03:22 0000009787  0000000000 ( 0.00%) 0.0000 0000012789  0000000000 ( 0.00%) 0.0001
Comments:By: Alexander Anikin (may213) 2012-01-10 23:00:50.008-0600

I think this is not a channel driver but RTP core trouble,
but will do some checking.
By: TSAREGORODTSEV Yury (tsarik) 2012-01-11 11:01:00.427-0600

I really can't understand in which cases its works......
I spent 17 hours non stop - and no results.

For sure all RTP media going thru asterisk.
I got one result for OUTGOING calls by sip.
When asterisk not getting RTP in this case - he interrupt call.
But for that I did changes in chan_sip.c:

string:
26029:  lastrtptx to lastrtprx
26030:  lastrtptx to lastrtprx
26043:  lastrtprx to lastrtptx (in 2 places)
26044:  lastrtprx to lastrtptx
26055:  lastrtprx to lastrtptx

In result its work only this way (outgoing call from asterisk by SIP if asterisk dont get RTP from calling party).
If called party stops send RTP asterisk still handle call.
I understand that what I did its incorrect but now its working somehow, in one direction :(((


By: Alexander Anikin (may213) 2012-01-13 10:55:13.575-0600

Yury,
there are two points which perhaps are issues.
1st - rtp timeout check in the channel driver but not rtp core (could be better to move this to rtp core)
And only SIP channel driver check rtp timeout now but not OOH323.

2nd - SIP channel driver check timeout for every packet per rtp session (rtp and rtcp).
I don't know what kind of checking is more correct - both type of packets or rtp only.
Idea of this checking is to check link loss as i think and from this point of view it is right
to check all packets.

I attach patch that change way of checking per rtp packets only but i'm not sure that it will come to mainline.

OOH323 don't check any rtp timeouts now and i'll produce patch few later here.

By: TSAREGORODTSEV Yury (tsarik) 2012-01-13 17:25:33.300-0600

Alexander,
thank your for help.
OOH323 has implementation
you also can find in configs rtptimeout option.
I will check this patch and will let you know soon results.

By: Alexander Anikin (may213) 2012-01-13 17:34:54.035-0600

Yury,
I known about options in config ;)
But they only affect to the rtp instance settings but rtp instance don't proccess these completely.
Patch for ooh323 will be soon.

By: Alexander Anikin (may213) 2012-01-13 17:40:31.991-0600

Yury, patch for ooh323 here also.
It is for asterisk 10 but must be clean for 1.8
Please test this patch.

By: TSAREGORODTSEV Yury (tsarik) 2012-01-13 17:54:49.465-0600

Alex :)
thank you so much :)
how everybody used asterisk before? :)
because RTP timeout very important function...
By: TSAREGORODTSEV Yury (tsarik) 2012-01-13 17:59:35.544-0600

F..K
:)
in sip channel other problem,
if call is SIP <-> SIP in any case * send P2P packets and dont do media proxy.
I tried already to change everything - directmedia (old canreinvite), directrtpsetup.
In any case if both sides have same codec and same protocol asterisk trying to redirect all media directly
between points..... should i open new ticket bug for that?
but for calls h323 <-> sip and for h323 <-> h323 i will test today and let you know results.
By: TSAREGORODTSEV Yury (tsarik) 2012-01-13 21:13:17.865-0600

Results are:
H323 -> doesn't work
SIP -> doesn't work
By: Alexander Anikin (may213) 2012-01-14 04:40:30.174-0600

Yury,

I think that sip channel driver establish local rtp bridge between both legs of call
if you disable directmedia. If directmedia enabled asterisk sip driver try to establish remote bridge
between sip peers directly.
You can disable rtp bridging by enabling jitterbuffer in sip.conf, just put jbforce=yes and jbimpl=adaptive in [general] section of sip.conf

By: Alexander Anikin (may213) 2012-01-14 07:24:09.143-0600

Yury,

corrected patch for ooh323 uploaded, pls try.
It tested and work in my environment.

By: TSAREGORODTSEV Yury (tsarik) 2012-01-16 14:36:47.652-0600

Alexander,
if it is possible please add me on skype: tsarik-108
or icq: 622719210 I have some interesting offer for you :)
By: Joshua C. Colp (jcolp) 2012-01-24 11:37:50.010-0600

I've put a patch in to fix rtptimeout support on 1.8 for SIP, so that should now be resolved (and I've tested all versions to confirm it). As this is now a solely a chan_ooh323 issue I will be moving on.

A few notes though:

1. The memset in the patch is not needed, calloc zeroes the memory already.
2. lastrtptx is used in places where lastrtprx should be used.
By: Alexander Anikin (may213) 2012-01-24 16:39:15.030-0600

Joshua,

patch without memset uploaded, lastrtptx was on wrong place in 1st version of patch (2nd patch had same filename), i just removed 1st.

But i have two common things about processing rtp timeout:

1. I'm not sure that checking timeout on rtp packets only (without rtcp packets as per attached patches) is more correct than checking both types of packets.

2. I think it would be better to implement checking of timeouts in the asterisk rtp engine and not in
channel drivers that perform signalling.

By: Joshua C. Colp (jcolp) 2012-01-25 10:24:58.861-0600

1. If RTP OR RTCP is received from the other side it is still alive.

2. Ideally yes but that would be an improvement for trunk only, not a bug fix.
By: Alexander Anikin (may213) 2012-01-26 02:12:51.297-0600

Original request from user for this issues is to check RTP packets only without checking RTCP (as i understand this request opposite side stop send voice but continue send rtcp)
Attached patches works according this request so they aren't bug fix for a while (except ooh323 don't have any rtp timeout checking now)

I think there is need to implement rtp timeouts in the rtp engine with configurable option how to
check timeouts - with or without rtcp.

By: Alexander Anikin (may213) 2012-06-19 18:20:21.032-0500

It's time to close this issue.
Patch for ooh323 goes to all supported version as bug fix documented option rtptimeout with checking only rtp packets. RTCP packets are not an indication of live voice from a side that send they.

Moving rtp timeouts to rtp core and improvements of rtp timeouts in another channel drivers is subject for separate issue and could be will open this later.

By: Dmitry Melekhov (slesru) 2012-09-13 01:16:35.035-0500

Hello!

I guess something is wrong in this patch.
I have call disconnections on rtp inactivity on dahdi-ooh323 calls with asterisk 10.7.0 on 61 seconds , but never on ooh323-dahdi.
So I just set rtptimeout to 0, will know soon does it help or not.