Summary:	ASTERISK-05529: Asterisk send BYE to an ext after get 2 invites messages
Reporter:	Lior Herman (mrsip)	Labels:
Date Opened:	2005-11-09 12:52:07.000-0600	Date Closed:	2011-06-07 14:10:50
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 5677.trace ( 1) asterisk2.log ( 2) ethreal.zip
Description:	we have an operator level soft switch work as sip. i opened 3 accounts on our SSW and used them as SIP/Trunk on Asterisk 1.2.x beta. I have no problem to register from Asterisk to our SSW with all those accounts Trunks numbers are 358753250900-903. i created 3 extensions on Astrisk as 900,901,902,903 and made DID for each SIP trunk. the registertion from Asterisk to our SSW done via Jasomi SBC. the asterisk PC is on LAN 192.168.200.X when Asterisk get income call from 358753250900 its ring on sip phone 900 register to asterisk. durring the converstion the SSW/Jasomi send every 1.5 min INVITE message to Asterisk. Asterisk reply with 200OK and get ACK back. then for some resone the Jasomi send again INVITE - asterisk Replay with 200OK, then its get ACK, but this time ASTERISK SEND BYE TO EXT 900 and hang up the call. I have all the traces in Ethreal if any body like. in sip.conf I use standard config (without nat as we use SBC) I can dial in and out without any problem. i noticed the problem accoure just when the two ends point are behind NAT using the Jasomi peer point. when i am dialing in using my mobile phone via PRI gate way that locate on the same subnet op the SSW its doen't happened because the Jasomi send only one Invite message. for some resone when Asterisk get one Invite after another it drop the call
Comments:	By: Lior Herman (mrsip) 2005-11-09 13:08:57.000-0600 hi would you please take a look on what i think is a bug in chan_sip bug id 5677 THNX By: BJ Weschke (bweschke) 2005-11-10 00:17:10.000-0600 As discussed on IRC #asterisk-bugs earlier today, we need a sip debug/trace to see why Asterisk is sending the BYE. By: Olle Johansson (oej) 2005-11-10 01:13:40.000-0600 Make a SIP debug with debug level set to 4 and verbose level set to 4. The reason we prefer this over ethereal captures is that we see what's going on inside your asterisk server. Thank you. By: Lior Herman (mrsip) 2005-11-10 09:51:18.000-0600 some explantion on the sip debug log file: income call from 0753250904 to 358753250901 (sip/trunk in *) asterisk ip 192.168.200.53 EXt 901 sip phone on ip 192.168.200.18 358753250901 have DID with 901. it might be codec negotiation problem as 0753250904 try first with g729, when i disabled g729 on the eyebeam converstion was longer. By: Lior Herman (mrsip) 2005-11-10 10:56:32.000-0600 with the great help of bweschke i manage to provide debug level 10 trace in the zip file By: BJ Weschke (bweschke) 2005-11-10 11:26:01.000-0600 MrSip: looking at your full trace, I could be wrong and will refer to oej's knowledge on this for confirmation, but I think we're actually receiving a BYE from your SBC first and the BYE you see going out to your extension is in response to the SBC's request to terminate the call. It would be interesting to see if you could determine from your SBC why it thought it was appropriate to terminate the call. By: Lior Herman (mrsip) 2005-11-10 13:31:09.000-0600 bweschke: I just check it again and can't see any BYE comming from my SBC. the call is start on 11:15:58 and end on 11:17:31. if you found any BYE that I skiped please tell me on what line you found it. By: BJ Weschke (bweschke) 2005-11-10 14:23:27.000-0600 oej: have a look at 5677.trace  best as I can tell, we're reading an RTP frame from the SBC right after the ACK comes from the SBC that is being interpreted as a g729 frame and that's what's blowing up this call. What's really strange though is that this call is up and running already as a ulaw call and we're tearing it down as a reaction to a mismatched frame type on the RTP??? <confused/> By: Lior Herman (mrsip) 2005-11-11 02:32:08.000-0600 after testing today i think the problem relay on eyebeam and not * as they start send g729 rtp. i tested from diffrent softclient and it worked g711 all the way. i will forward the traces to xten for comment and will update this page. By: BJ Weschke (bweschke) 2005-11-11 08:06:03.000-0600 MrSip: this does appear to be a client issue and not necessarily a problem with chan_sip in Asterisk. Can we close this bug now based on these findings? By: Lior Herman (mrsip) 2005-11-11 08:55:55.000-0600 bweschke: just for be on the safe side i would like to wait XTEN repond as i send them the problem for comment. if its ok by you lets wait for next weak and i will also will publish the result i will get from Xten so if some one will get same thing in the future all data will be avalible here. what do you think? By: Lior Herman (mrsip) 2005-11-15 12:35:01.000-0600 bweschke:Haven't got yet answer from Xten so I think we can close this one By: BJ Weschke (bweschke) 2005-11-15 12:39:30.000-0600 closed per user request. SIP client issue.