Summary:	ASTERISK-08690: Incorrect SDP in header when not native bridging
Reporter:	atca_pres (atca_pres)	Labels:
Date Opened:	2007-01-30 10:19:37.000-0600	Date Closed:	2007-03-26 15:12:23
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) HalfBridge.zip
Description:	When I add the Tt option in the dial cmd, native bridging is impossible between two users. Asterisk does not reinvite the calling party. It does, however, when the Tt option are missing. The called party's rtp is sent directly, no matter what. The problem is that Asterisk doesn't reinvite the calling party with the new address. I thought with Asterisk 1.4 it was suppose to put the ip address directly instead of doing a re-invite. ****** ADDITIONAL INFORMATION ****** I'm using SIP INFO and both party can send DTMF to asterisk. I have set nat=never canreinvite=yes dtmfmode=info and the dial cmd exten => _XXXX,1,Dial(SIP/${EXTEN},,Tt) OR exten => _XXXX,1,Dial(SIP/${EXTEN},,) I've included config files sip debug with core and verbose 4. Also include wireshark captures.
Comments:	By: Tilghman Lesher (tilghman) 2007-01-31 08:01:27.000-0600 Of course it can't native bridge.  The whole point of 'tT' is that Asterisk MUST stay in the middle of the call, in order to intercept DTMF to determine whether to initiate a transfer. This is intentional behavior and is therefore not a bug. By: atca_pres (atca_pres) 2007-01-31 13:50:06.000-0600 Asterisk doesn't have to stay in the RTP media path. I'm using SIP INFO DTMF (as mentionned). Asterisk will catch them anyway. In fact, even if Asterisk stays in only one of the two media path (which is really weird and a bug imho) asterisk catch DTMF from both phone. Breifly, Asterisk should not stay on only one Media path, either in both, or even better in none when using DTMF SIP INFO. All that is missing is either the address change in the 200 OK to the calling party or a reinvite. Please look at the capture to see that asterisk stays in only one media path and does it uselessly. Thank you By: Tilghman Lesher (tilghman) 2007-01-31 14:19:42.000-0600 The problem is that at the point of deciding whether or not to bridge, Asterisk does not know any of the details of how DTMF is transmitted.  If it has to listen, it will stay in the middle of the call and will not attempt to native bridge. Remember, Asterisk is a gateway, NOT a proxy.  What you're asking for here would be the behavior of a proxy. By: atca_pres (atca_pres) 2007-01-31 14:44:10.000-0600 Asterisk surely considers options in the user (sip.conf) like Canreinvite=no or nat=never to determine if it can native bridge or not. Is surely can look in dtmfmode too. Asterisk has no reason to stay in half of the media path. (Remember that Asterisk keep the calling party's rtp to him and bridge the called party directly to the calling party) I'm no programmer, but if Asterisk can look at the canreinvite and nat options, it can also look at the dtmfmode. Asterisk has all it needs to native bridge at the re-invite time. I don't want a proxy, I just want to keep Asterisk out of the media path as much as possible. By: Tilghman Lesher (tilghman) 2007-01-31 14:53:59.000-0600 No, it really doesn't consider those things when it comes to native bridging or not.  Those options are only considered AFTER the core decides to allow native bridging.  The two flags that you are using 'Tt' prevent the core from even considering native bridging. By: atca_pres (atca_pres) 2007-01-31 15:02:50.000-0600 Then it is a bug that the rtp from the called party is sent directly to the calling party instead of Asterisk ? Roughly the rtp does : Caller ->Asterisk Asterisk -> Called Called -> Caller    <--Why this then ? If asterisk was to listen on the rtp coming from the called party it would be impossible !! You can always transform this incident in a Feature request, but I really think that Asterisk tries to do native bridge here and fail. By: Tilghman Lesher (tilghman) 2007-02-02 11:08:14.000-0600 As a feature request, this does not belong on the bugtracker.  Feature requests are tracked on the Wiki.  Please place your request there.  This bug is suspended until you have a prospective patch. Please do not reopen until you have a prospective patch. By: atca_pres (atca_pres) 2007-02-02 23:26:56.000-0600 I don't think you understand the issue and you do not answer all my question. Please take time to understand what I'm saying here. It is not normal that the rtp does : Caller ->Asterisk Asterisk -> Called Called -> Caller There is a reinvite missing here so that it does: Caller -> Called Called -> Caller If I wasn't in SIP INFO, the dtmf from the called party would never reach Asterisk. By: Tilghman Lesher (tilghman) 2007-02-03 18:49:21.000-0600 Again, this is a feature request.  Feature requests do not belong here. Please do not reopen this bug again until you have talked with a bug marshal. By: Tilghman Lesher (tilghman) 2007-02-05 17:14:58.000-0600 Reopening, with a different subject.  The SDP address is definitely wrong. By: Serge Vecher (serge-v) 2007-03-07 11:32:06.000-0600 any difference with 1.4.1 release? By: atca_pres (atca_pres) 2007-03-08 09:59:06.000-0600 I have tested with Asterisk SVN-branch-1.4-r58354 Even if it is not what I expected, now the SDP is correct. I thought that instead of the rtp portal the sdp would have been directed directly between the endpoints. Now SIP INFO don't work in transfers. Do you want me to enter a new incident for this ? By: Serge Vecher (serge-v) 2007-03-21 14:13:15 atca_pres: yes, please open a new ticket with a sip debug attached for the SIP INFO issue. By: Joshua C. Colp (jcolp) 2007-03-26 15:12:22 Since the SDP is now fixed I'm closing this out - as for the INFO bug if it's still an issue please open a new bug with all the information you can!