|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:44||Date Closed:||2012-05-04 10:21:32|
|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 ...)
Phone A Asterisk Phone B
Invite (SDP A) -> -> Invite (SDP Asterisk)
<- Ringing --- <- Ringing
<- o.k. (SDP B, Codecs filtered) --- <- o.k. (SDP B)
-> ACK -> ACK
-> Re-Invite (SDP A, Codecs Filtered)
<- o.k. (SDP B)
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
please see the related attached sip & core debug trace file and a tcpdump trace file.
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 18.104.22.168
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
I apologize for the delay!
To push on this issue, Günther Kelleter will test the patch tomorrow and give you the requested results.
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
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?
By: Thomas Arimont (tomaso) 2012-05-23 02:48:34.015-0500
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.
By: Thomas Arimont (tomaso) 2012-05-31 09:20:34.534-0500
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).
By: Thomas Arimont (tomaso) 2012-05-31 09:49:28.172-0500
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
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.
By: Thomas Arimont (tomaso) 2012-06-04 11:49:05.765-0500
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 ...