Summary:	ASTERISK-09366: BYE calls too fast when connected to a mediatrix box makes asterisk acts weird
Reporter:	Caio Begotti (caio1982)	Labels:
Date Opened:	2007-05-02 07:00:06	Date Closed:	2007-11-19 12:34:12.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) probtrans.cap ( 1) pstn2mediatrix_loop_ok.txt ( 2) pstn2mediatrix_zombie.txt ( 3) sip_debug1.txt ( 4) sip_debug2.txt ( 5) sip_history.txt ( 6) transOk.cap
Description:	To be honest I started getting a little confused about the nature of this, but according to the folks from ticket 9305, that is what's happening (the original logs from the calls are attached): one47: I think that the re-INVITE patch is behaving correctly, and that you are seeing a different problem. The problem occurs at the point of the transfer. The REFER message is sent to asterisk, which IMMEDIATELY responds "202 Accepted", and then send a "200 OK" to indicate completion, where in fact it has not yet started the transfer process in the background. At this point MxSipApp decides to hangup the 2 channels it just joined. If it does this quickly enough, the BYE request disrupts the transfer (which is not yet completed.) If you are lucky, MxSipApp is slow enough that the transfer has begun, and can proceed normally. atca_pres: This is a known issue with Mediatrix product (well from me anyway) Enter a new issue for this one. The behavior has been there for a while. If the Mx bye all the calls, Asterisk start acting weird. You can see in your capture probtrans that Asterisk Bye a call before receiving the 200 Ok fron the invite he just sent. And then when the call is over, Asterisk seems to answer it's own INVITE with 200ok to the Mx unit.
Comments:	By: Caio Begotti (caio1982) 2007-05-02 07:02:05 Could someone add a relationship from this ticket to 9305? By: Olle Johansson (oej) 2007-05-02 07:43:54 DO NOT add pcap files to bug reports in the ASterisk bug tracker. DO read the bug guidelines, as requested when you open a bug report - they clearly state that we need SIP debug output and how you generate it. Thanks. By: atca_pres (atca_pres) 2007-05-03 14:05:38 caio1982 Can you give a little more detail of your scenario ? A : Mediatrix ?? 10.143.136.109 "5003" B : Asterisk 1.4r61618 10.142.192.102 C : Mediatrix ?? 10.143.137.251 "5001" D : Mediatrix ?? 10.143.137.251 "5002" A calls C A Flash hook -> C on hold A calls D D answers A and D talk A hangs up (attended transfer) And then ? Is that correct ? Before you applied the patch you were having a 500 internal. Now with the patch, no 500 but call doesn't work wither. right ? By: atca_pres (atca_pres) 2007-05-03 14:08:19 Also, did you try the sip_reinvite4.diff suggested by one47 ? By: Caio Begotti (caio1982) 2007-05-03 14:20:40 No, atca_pres, I didn't have the chance to test sip_reinvite4.diff until now, I'll need to workaround this for a while so I can apply the patch and check what changes then. The current scenario is: A: Nortel's MCS (call from PSTN) B: Asterisk 1.4-r62005M with sip_reinvite3.diff C: Mediatrix 10.143.136.109 "5007" D: Mediatrix 10.143.136.109 "5008" A calls C C flash hook -> A on hold C calls D D answers C and D talk C hangs up (attended transfer) Then... sometimes it works, sometimes it does not. A and D should talk, but it doesn't work all the time we try. I could not figure out the difference from a working call and a not-working one yet. We changed the scenario a little bit but I don't think that will make the results any different. I'll try to test sip_reinvite4.diff ASAP, the problem with its test is that I screwed up things not related to this SIP issue in my build... And yes, there's no 500 internal error anymore, at least with sip_reinvite3.diff. By: Caio Begotti (caio1982) 2007-05-03 14:23:00 Attached are two debug logs from 2 calls with the same problem and the sip history from them (I had so many channels in the history list that I just hope these are the correct ones). By: Caio Begotti (caio1982) 2007-05-04 09:33:17 I've tested the patch sip_reinvite4.diff and it seems to be more stable than the others before it. Most of the transfer from PSTN to Mediatrix, passing through Asterisk, and from Mediatrix to Mediatrix, passing through Asterisk as well (of course) works fine. However, sometimes it still just hangup with a busy tone or sometimes it works but gives a ZOMBIE channel message. I'd say that after 15 attempts of transfer only 2 didn't work at all. The following lines appeared in my logs right now and I don't know what to do with them. Is it a totally different problem or the messages below are still related to this issue? DEBUG[23163]: chan_sip.c:1681 parse_sip_options: Begin: parsing SIP "Supported: em,100rel,timer,replaces,path,com.nortelnetworks.firewall,p-3rdpartycontrol,nosec" DEBUG[23163]: chan_sip.c:1689 parse_sip_options: Found SIP option: -em- DEBUG[23163]: chan_sip.c:1703 parse_sip_options: Found no match for SIP option: em (Please file bug report!) DEBUG[23163]: chan_sip.c:1689 parse_sip_options: Found SIP option: -100rel- DEBUG[23163]: chan_sip.c:1695 parse_sip_options: Matched SIP option: 100rel DEBUG[23163]: chan_sip.c:1689 parse_sip_options: Found SIP option: -timer- DEBUG[23163]: chan_sip.c:1695 parse_sip_options: Matched SIP option: timer DEBUG[23163]: chan_sip.c:1689 parse_sip_options: Found SIP option: -replaces- DEBUG[23163]: chan_sip.c:1695 parse_sip_options: Matched SIP option: replaces DEBUG[23163]: chan_sip.c:1689 parse_sip_options: Found SIP option: -path- DEBUG[23163]: chan_sip.c:1695 parse_sip_options: Matched SIP option: path DEBUG[23163]: chan_sip.c:1689 parse_sip_options: Found SIP option: -com.nortelnetworks.firewall- DEBUG[23163]: chan_sip.c:1703 parse_sip_options: Found no match for SIP option: com.nortelnetworks.firewall (Please file bug report!) DEBUG[23163]: chan_sip.c:1689 parse_sip_options: Found SIP option: -p-3rdpartycontrol- DEBUG[23163]: chan_sip.c:1703 parse_sip_options: Found no match for SIP option: p-3rdpartycontrol (Please file bug report!) DEBUG[23163]: chan_sip.c:1689 parse_sip_options: Found SIP option: -nosec- DEBUG[23163]: chan_sip.c:1703 parse_sip_options: Found no match for SIP option: nosec (Please file bug report!) By: Caio Begotti (caio1982) 2007-05-04 09:34:45 Both pstn2mediatrix_zombie.txt and pstn2mediatrix_loop_ok.txt are related to sip_reinvite4.diff that we tested in our lab minutes ago. One is the log for the call that didn't work and the other is the working call but still with those weird loop messages inserted by the patch. By: Caio Begotti (caio1982) 2007-09-25 14:27:18 I should tell you that since some weeks ago I don't have any access to this Mediatrix box anymore. I hope other people can keep providing newer test results. Anyway, I believe bug 9305 with one47's latest patch solves all that. By: Olle Johansson (oej) 2007-11-19 11:48:36.000-0600 Since the patch in ASTERISK-9034 has been committed - can we close this issue too? By: Steve Davies (one47) 2007-11-19 12:29:28.000-0600 Yes, I believe that 9305 covers this ticket too. By: Olle Johansson (oej) 2007-11-19 12:34:11.000-0600 Fixed with the patch in ASTERISK-9034. Thanks to everyone involved in this bug report!