Summary:	ASTERISK-08528: asterisk will not handoff RTP!!!
Reporter:	AlexG (greekman)	Labels:
Date Opened:	2007-01-09 09:05:36.000-0600	Date Closed:	2011-06-07 14:11:54
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sip98.cap ( 1) verbosedebug.txt
Description:	Hi all! Let me start by saying that I have researched the heck out of this topic everywhere, but can't seem to find a solution. Maybe you guys can shed some light on the issue: Currently I am using asterisk to bridge 2 call legs via a carrier VOIP connection to Verizon. This connection is a bit different from what I've seen in the past, but to my knowledge has no effect on the issue at hand. Just to have it noted this is how the connection works: We set up an IPsec tunnel to verizon and placed our box behind a ranch rn20 VOIP router/firewall. The ip adress of the box is a public address that is directly routed down to it via the rn20, there is no NAT being used whatsoever. The sip traffic gets sent through the tunnel, and the rtp is sent out over the public net once calls are established. Firewall is completely wide open for this * box, no limitations whatsoever Both call legs get generated on the same box and to the same pstn gateway. We are trying to get the legs to reinvite on themselves down at the gateway. Verizon is telling us that the feature is available and should work if we can manage to get * to send the reinvite. The sip.conf profile for the gateway has canreinvite=yes what we've tried so far: 1. we tried creating 2 sip.conf profiles, one for each leg. the proxy for our sip gateway has 2 available ips for us to connect to, so we dedicated one to each, hoping that maybe * wasn't re-inviting because of confusion of using the same profile did not work 2. we tried several different settings for dtmf handling in both sip.conf profiles didn't work 3. we tried forcing different codecs (the same for both profiles, just different ones being used on each try) didn't work 4. we removed all flags from the dial command did not work 5. we pulled our hair out and tried a spirit dance did not work In all cases I did ethereal captures and it's plain to see that * is just not sending the reinvite at all. Both call legs get set up OK, but until either leg hangs up, there is no sip messaging sent by * for the reinvite to occur. (I've attatched an ethereal capture here so you can confirm that the SDP is showing availability for the reinvite by verizon. Process for a call setup: Leg 1 gets called. on answer, it sends call into macro where some media is played and dtmf input is requested. if dtmf is correct, channel exits macro and is sent into an extension that dials leg 2 leg 2 answers and * bridges the calls at this point * should handoff rtp, it doesn't here are the dial strings: although there are alot of variables used in our dialplan, below is an example of the dial string for each leg fisrt leg: -- AGI Script Executing Application: (DIAL) Options: (SIP/140XXX11072@verizon|90|M(vendor^1^15^1^698a^)) second leg -- Executing Dial("Local/333@initiate_call-698a,1", "SIP/+1860XXX2300@leg2verizon|90|(8460000|30000)") in new stack so after my long winded description i ask the following.... how do I get * to issue the reinvite?
Comments:	By: Serge Vecher (serge-v) 2007-01-09 09:36:30.000-0600 As per bug guidelines, you need to attach a SIP debug trace illustrating the problem. Please do the following: 1) Prepare test environment (reduce the amount of unrelated traffic on the server); 2) Make sure your logger.conf has the following line:   console => notice,warning,error,debug 3) restart Asterisk with the following command:   'asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt' 4) Enable SIP transaction logging with the following CLI commands: set debug 4 set verbose 4 sip debug 5) Trim startup information and attach verbosedebug.txt to the issue. By: AlexG (greekman) 2007-01-09 13:34:20.000-0600 ok, i've uploaded the file By: Serge Vecher (serge-v) 2007-01-09 13:43:52.000-0600 /n option added for dialing the local channel will prevent the reinvites. By: Joshua C. Colp (jcolp) 2007-01-09 13:45:38.000-0600 Your call is going through chan_local so the SIP channels are not directly bridged and thus can't reinvite. By: AlexG (greekman) 2007-01-09 14:41:54.000-0600 maybe u guys can give a small piece of advice here... what it all comes down to is that we use * as a click to call platform. we use .call files to initiate calls. the only way we have found to initiate the first leg of the call whil allowing it to interact with a macro has been by placing the channel to local and directing the first leg into an extension wher ethe dial command is executed with "M" to allow access to the macro. if the macro conditions are met, leg one leaves the macro and dials leg 2 is there another way of doing this? By: Joshua C. Colp (jcolp) 2007-01-22 22:41:00.000-0600 Since this is not a bug and nobody has any information to help you I would suggest going to the asterisk-users mailing list or the IRC channel, explaining the situation, and seeing what people can suggest. Thanks!