Summary:	ASTERISK-03910: Asterisk needs to be able re-initialise the RTP stream processing after a re-invite
Reporter:	marvy (marvy)	Labels:
Date Opened:	2005-04-11 04:54:27	Date Closed:	2005-04-20 10:29:38
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sip-debug
Description:	The SIP peer my asterisk server connects to for some reason likes to send a re-invite after the call has been established for 600 seconds. After the re-invite has been ACKed by the asterisk server, the peer starts using a new SSRC, Sequence Number and Timestamp offset. At this point I lose incoming audio to my call although I can still see the data streaming in. I presume asterisk is not prepared for this change of timestamp offset after a re-invite and the codec is then unable to reconstruct the audio stream.   ****** ADDITIONAL INFORMATION ****** Please find attached a tcpdump (readable in ethereal) of the whole 10 minute call. At around the 606 second mark of the capture (packet 40131) you see the re-invite. The incoming SSRC, Seq and Timestamp change to new random init values. At this time, asterisk is unable to decode the incoming audio stream. Outgoing audio is file.
Comments:	By: marvy (marvy) 2005-04-11 04:59:17 Sorry the upload didn't work. The tcpdump can be retrieved from ftp://ftp.uq.edu.au/incoming/full.zip By: Kevin P. Fleming (kpfleming) 2005-04-13 01:00:42 I don't believe this is RFC compliant behavior; when an RTP media stream is continuous, the timestamps should be monotonically increasing under all circumstances. Please ask your SIP provider to give us some indication of why they feel their gateway is acting in a compliant manner... without a strong reason to change Asterisk, I'd think this is just plain incompatibility on their part. By: marvy (marvy) 2005-04-13 20:56:42 I guess it depends on how you look at it. You can say they are starting a new stream using the same part and IP that the last one used. I can tell you that every softphone and my SPA-3000 all handle this situation just fine. Do you want asterisk to be just strictly RFC complient and not actually work in the real world or would you prefer the software to follow the sendmail model and be strictly RFC complient in what it sends but very liberal in what it accepts? I don't see any harm in adding this functionality to asterisk. It doesn't make asterisk violate any RFC's it just makes it a better and more compatable product in the long run. I am fairly new to asterisk and I am slowly trying to find my way around the code. I am going to try and create a patch for this, I really would like you support in this matter. By: Olle Johansson (oej) 2005-04-17 09:28:27 Can you please attach a SIP debug of the SIP transactions when this happens? Set debug level to 4 at verbosity to 4 and turn on SIp debug. By: Olle Johansson (oej) 2005-04-17 09:29:41 If the re-invite has an SDP, I think we should consider this as a change of RTP stream and restart the RTP subsystem, like any re-invite - even though this uses the same RTP peer. By: marvy (marvy) 2005-04-17 15:48:19 I have attached a debug file I had at hand. I hope it shows sufficient information. The REINVITE *does* contain a valid SDP header. Please also note the WARNING generated in the last line. This as caused by another bug in asterisk (see bug 4002). I will generate a move verbose debug shortly. By: marvy (marvy) 2005-04-19 05:24:46 I think I have further diagnosed the problem I am having here. The skip in time stamp in the RTP stream is being passed on through the codec's to the IAX2 softphone I am using. I am guessing now that its the softphone I am using that is having trouble with the changing time stamps. I assume that after the REINVITE on the SIP connection, asterisk should also do something to the IAX2 connection on the other side to tell it that the time stamps have been changed. By: Olle Johansson (oej) 2005-04-19 11:32:46 Need a SIP debug of the full call, the first invite and then the re-invite and the hangup. Please set verbosity to 4 and debug level to 4. What kind of device is on the other end of the call? By: marvy (marvy) 2005-04-19 16:01:00 I was using iaxcomm softphone on my PC calling through asterisk to a service provider. I don't know what hardware they have. At 10 minutes they send a REINVITE . At that point, the call doesn't drop, I just lose incoming audio. I can see the RTP packets streaming in and out plus the IAX packets are still coming in and out to the softphone. What seems to cause the problem is that the service provider changes their timestamp. Initially I thought that asterisk was getting confused by this however it seems to me that asterisk just passes this timestamp through multiple codecs and out the other side! (bug?) In the end, I presume it was infact the iaxcomm softphone that was having trouble with the change in time stamp. I switched to X-Lite and the call proceeded just fine. So if you think its OK for asterisk to just pass these time stamps through the codecs then I guess this bug can be closed. It means that asterisk can potentially spit out weird stuff when it gets weird stuff passed to it. I will run the SIP debugs for you shortly. By: Kevin P. Fleming (kpfleming) 2005-04-20 10:29:03 Well, Asterisk is not going to be able to do anything about timestamp changes in a pure RTP bridge (it may be able to do so in an RTP-IAX2 bridge, but I'm not sure it would be a good idea). Any device with a jitter buffer is going to have problems with the timestamps resetting like this, so I don't think this is something that Asterisk can handle (or accomodate). Even a SIP-ZAP call using the Asterisk jitter buffer will experience bad effects if the RTP timestamps suddenly change. For that matter, most complex codecs keep 'state' from the previous frames, and if we reset the RTP session and the codec when this re-INVITE comes in, there will be audio damage because the first few frames in the new session won't have the state left over from the last frames of the old session. I'm going to close this for now as 'wontfix', since I don't really think that there's anything that Asterisk can do to help the situation here.