|Summary:||ASTERISK-11308: Incorrect dialog matching and requests on blind transfer|
|Reporter:||Grey VoIP (greyvoip)||Labels:|
|Date Opened:||2008-01-26 08:05:55.000-0600||Date Closed:||2011-06-07 14:10:31|
|Environment:||Attachments:||( 0) incorrectdialogonbye.txt|
( 1) incorrectdialogonbye-siptrace.txt
|Description:||Two problems were noticed with Asterisk SIP handling when a blind transfer takes place. The problems are relatively trivial and do not affect the transfer completing, this bug is being logged for completeness.|
The first issue is that after the REFER request has been processed the first NOTIFY is sent by Asterisk and the response to that NOTIFY request is not matched and the request is re-transmitted until timeout. Subsequent NOTIFY requests do get macthed correctly so the issue only applies to the very first NOTIFY sent.
The BYE request generated by Asterisk to hangup the original call has the From and To headers incorrectly set. Instead of having them set as per the established dialog it has them reversed as if the request were a NOTIFY.
http://www.tech-invite.com/Ti-sip-service-4.html#fig9 was used as a reference.
|Comments:||By: Olle Johansson (oej) 2008-01-27 04:46:33.000-0600|
The notify stuff is very hard to fix at this moment, but the BYE should be fixable.
By: Joshua C. Colp (jcolp) 2008-04-07 10:05:40
So the NOTIFY issue is being caused by chan_sip sending 2 NOTIFY packets, one to provide "fake" ringing and the other to confirm the transfer has completed. Removing the fake ringing one causes it to work fine.
By: Olle Johansson (oej) 2008-07-03 12:00:50
The BYE is sent from Asterisk with the correct From: header and tag. The request is in direction from Asterisk to your device.
INVITE sip:email@example.com SIP/2.0
BYE sip:10.0.0.100:6592 SIP/2.0
The tag on the From is the same as in the 200 OK, so I see no issue there. Can you please explain?
By: Grey VoIP (greyvoip) 2008-10-26 07:34:32
You are right the BYE request is correct, my mistake, apologies.
By: Mark Michelson (mmichelson) 2008-12-09 18:18:14.000-0600
The issue of the NOTIFYs here comes down to a fundamental flaw in Asterisk's SIP stack. That is, Asterisk cannot maintain multiple outgoing transactions for a single dialog. In the case where Asterisk transmits two requests without receiving a response in between, the response to the first request will be ignored every time.
This issue has been a longstanding one in Asterisk and needs to be fixed. The problem is that it is not a problem which is likely to be fixed any time soon due to the importance of other work and the fact that adding such support is not a trivial task at all.
Because there are other bugs open on the tracker which boil down to the same basic issue, and this one is by the reporter's admission not something which adversely affects the functionality of Asterisk during transfers, I am electing to suspend this issue in favor of those issues which actually do impair the ability of Asterisk to properly function.