Summary:	ASTERISK-19294: Asterisk 1.8.6.0 failed to switch RTP destination when receiving a SIP reinvite
Reporter:	Gareth Blades (gblades_skymarket)	Labels:
Date Opened:	2012-02-02 09:00:21.000-0600	Date Closed:	2012-02-10 14:12:54.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:	1.8.9.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) test.cap ( 1) WIL-73666-797sip.txt ( 2) WIL-73666-797tcpdump.txt
Description:	We have a sip voip provider we use that we send many calls through to (over 10,000 a day) and for one particular destination number we are experiencing a one way audio issue. There is definetly something strange with the session as you can see from teh time breakdown shown below but at the end we do receive a SIP 200 with an invite from the other end giving the new IP and port we should send audio to (the time we get this corresponds with when the call was answered) but for some reason Asterisk continues to send traffic to the old address even though it ACK'd the reinvite. I dont know if its a bug, related to the fact that we were getting ICMP unreachables for a while, already receiving RTP from the new IP address and port for 5 seconds or if there was some sort of sytax issue with the reinvite packet. 12:59:28.535575 call attempt made 12:59:29.388210 session progress telling us audio connection is to 87.238.74.139 port 19374. At this point two way RTP is established. 12:59:48.946231 Other end stops sending RTP to us 12:59:49.241692 RTP starts being sent to us from 213.166.5.143 port 18994 12:59:49.433346 we start receiving ICMP unreachable messages for the traffic we are still sending to 87.238.74.139 port 19374. 13:00:05.312570 we finally receive a sip 200 response with the new audio destination but we still send RTP to the old IP address.
Comments:	By: Gareth Blades (gblades_skymarket) 2012-02-02 09:01:02.273-0600 SIP Trace By: Gareth Blades (gblades_skymarket) 2012-02-02 09:01:36.909-0600 tcpdump output showing the ip's and ports for the rtp traffic By: Matt Jordan (mjordan) 2012-02-09 16:05:17.262-0600 I think we'll need a pcap from wireshark to debug this, as its hard to correlate the RTP and SIP messages without it.  What I can say is that the UA Asterisk is sending messages to changes the RTP address both in the 183 and in the 200 OK - but I can't tell which address we're sending to after the 200. By: Gareth Blades (gblades_skymarket) 2012-02-10 04:00:07.636-0600 tcpdump of an affecting call By: Gareth Blades (gblades_skymarket) 2012-02-10 04:04:25.035-0600 The following is the comment from our peer telco who we sent the call to when they investigated what was going wrong :- "I've had a look though this ticket, and what has happened with this call is that we have presented it to one carrier, and at that point the first 183 would have been issued. However, for a reason indeterminate at this point we have not been able to complete the call with them, so the call would have been switched to a different carrier and gateway to complete the call. The 200OK would have been issued from the new gateway. This is not a reINVITE process, and it is valid to serve up a different address in the 200OK to that received in the 183 Session Progress and Asterisk should have dealt with this. However, when we changed gateways it would have been ideal to send a new 183 Session Progress and this might have helped Asterisk handle the situation." Then a follow up email a bit later :- "I believe in this case we should now send two 183 Session Progress, one for the original gateway and one for the new one, so hopefully your Asterisk server will deal with this now. I need to stress that this is an Asterisk bug as what we were doing was perfectly permissible. " Hopefully the tcpdump I have just attached will help as we probably cant reproduce the problem anymore with the workaround the other telco has implemented. Regards Gareth By: Matt Jordan (mjordan) 2012-02-10 08:28:16.248-0600 Gareth: The attached pcap does not demonstrate the problem description. Packet 6: 183 Session Progress with an RTP destination of 87.238.74.139 Between packet 6 and 1677, Asterisk sends RTP to 87.238.74.139 Packet 1677: 200 OK with an RTP destination of 87.238.74.139 Asterisk continues to send RTP to 87.238.74.139 Since the pcap doesn't match the description from the provider, I'm guessing this doesn't demonstrate the issue. By: Gareth Blades (gblades_skymarket) 2012-02-10 08:43:41.829-0600 Ok I think the best thing would be if you close the ticket as we cant reproduce the problem anymore with the changes the other telco has made. The tcpdump I took must have been an odd occurance when the call did work properly to the particular number. If I notice the problem again in the future I will reopen or create a new ticket and include an actual tcpdump rather than a trace. Regards Gareth