[Home]

Summary:ASTERISK-19620: directrtpsetup is not working anymore as expected/as in earlier Asterisk versions
Reporter:Thomas Arimont (tomaso)Labels:
Date Opened:2012-04-02 11:20:44Date Closed:2012-05-04 10:21:32
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/Messaging
Versions:1.8.9.3 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) 350975.diff
( 1) sipdebug_coredebug.txt
( 2) tcpdump.cap
Description:As already mentioned in http://lists.digium.com/pipermail/asterisk-dev/2011-April/048859.html the sip option directrtpsetup is not working as in earlier versions Asterisk 1.4/1.6 anymore.

For a call setup it looks like this (additional Re-Invite ...)

{noformat}
Phone A  Asterisk          Phone B
Invite (SDP A) ->                  -> Invite (SDP Asterisk)
<- Trying
<- Ringing                        ---       <- Ringing
<- o.k. (SDP B, Codecs filtered)  ---       <- o.k. (SDP B)  
-> ACK                                      -> ACK
                                           -> Re-Invite (SDP A, Codecs Filtered)
                                           <- o.k. (SDP B)  
                                           -> ACK
{noformat}

I'm afraid you will point to the 'experimental' character of the directrtpsetup option ... but this is really more than just a nice feature.
Comments:By: Matt Jordan (mjordan) 2012-04-02 13:20:26.442-0500

It is experimental, but that doesn't mean this isn't an issue.  Do you mind attaching a SIP trace and a DEBUG log all the same?
By: Thomas Arimont (tomaso) 2012-04-03 02:57:35.254-0500

Matt,
please see the related attached sip & core debug trace file and a tcpdump trace file.
Thomas
By: Joshua C. Colp (jcolp) 2012-04-10 10:00:24.907-0500

After examining this issue I have determined that it has already been fixed in the 1.8 branch but has not yet made it to a release. As a result I have attached the fix to this issue and confirmed it applies cleanly to 1.8.9.3
By: Matt Jordan (mjordan) 2012-05-02 08:27:51.719-0500

Thomas: did you ever get a chance to confirm that this was fixed by the patch Josh put on this issue?
By: Thomas Arimont (tomaso) 2012-05-02 10:47:19.047-0500

Joshua, Matt,
I apologize for the delay!
To push on this issue, Günther Kelleter will test the patch tomorrow and give you the requested results.
Thomas
By: Guenther Kelleter (gkelleter) 2012-05-03 03:47:24.611-0500

The attached patch applies cleanly and fixes the issue.
By: Matt Jordan (mjordan) 2012-05-22 12:39:12.687-0500

Thomas/Guenther:

Just to confirm, I show this patch as being in Asterisk 1.8.11-cert1 (line 1451-1453 of rtp_engine.c).  This should be resolved in Certified Asterisk - does your testing indicate that?

Thanks,

Matt

By: Thomas Arimont (tomaso) 2012-05-23 02:48:34.015-0500

Matt,
we haven't test this yet for the certified 1.8.11 release. But I had assumed this bugfix didn't make it to the 1.8.11-cert1 since I haven't found a relating entry in the changelog. Good to know that I was wrong.
We would let know if there are any problems.
Thomas
By: Thomas Arimont (tomaso) 2012-05-31 09:20:34.534-0500

Matt,
after doing some further tests in our lab (with asterisk 1.8.11-cert1 release) I am not really sure anymore if the patch does/can really fix the problem we had reported anyway.
There is one thing I haven't considered yet: direct rtp setup does only work if the target is a single target. Infact the dialplan of the/our used asterisk (Gemeinschaft) forces a parallel call everytime the target is in a specific 'pickuproup' (a dummy LOCAL channel is dialed in parallel). This is a weird dialplan hack to compensate the problem with the faulty display of SIP Notifies (remember our feature request design work regarding this).
So the patch could be necessary and o.k., but it cannot solve our 'problem' with direct rtp setup and parallel calls (since this - the suppressing of early media in case of parallel calls - is a wanted behaviour).

Thomas
By: Thomas Arimont (tomaso) 2012-05-31 09:49:28.172-0500

Matt,
I've talked to Günther once more. We have definitely verified the patch in our asterisk environment (testing before and after patching). It fixes the intial described faulty behaviour.
The issue I've described in my last comment is a separate thing, although it looks very similar.

By: Matt Jordan (mjordan) 2012-05-31 13:21:10.967-0500

Thomas:

If that's the case, then lets go ahead and close this issue out and open a new one for the new problems.  I wouldn't want to muddy the water (so to speak) by trying to track two behavior problems on a single issue.

Matt
By: Thomas Arimont (tomaso) 2012-06-04 11:49:05.765-0500

Matt,
I'm not sure if there is a reason to open a further ticket here yet, since there is no actual bug with this second issue.
Although I would like to bring up a question here:
Is it really necessary to couple the 'directrtpsetup' function indirectly to the 'earlybridge' functionality?
Since 'earlybridge' is prohibited if a call is a 'parallel/forked' call - which obviously is quite reasonable - , directrtpsetup is prevented as well in this case.
I guess that the ladder is reasonable too ...

Thomas