Summary: | ASTERISK-10000: RTP Stream with wrong Timestamp after 200 ok when 183 session in progress | ||
Reporter: | wdecarne (wdecarne) | Labels: | |
Date Opened: | 2007-08-01 09:43:19 | Date Closed: | 2008-03-05 18:03:35.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) 10355.diff ( 1) rtp_debug.log | |
Description: | Call Flow ISDN -> Gateway -> SIP -> Asterisk Server -> SIP -> Gateway (same) -> ISDN GW->Asterisk (Call 1) INVITE sip:0xxxxxxx@172.16.0.26 SIP/2.0 From: <sip:0yyyyyyy@172.16.0.26>;tag=-115824375 To: <sip:0xxxxxxx@172.16.0.26> Content-Type: application/sdp Content-Length: 249 v=0 o=- 1185978976 1185978977 IN IP4 192.168.1.156 s=- c=IN IP4 192.168.1.156 t=0 0 m=audio 40028 RTP/AVP 8 0 18 4 2 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:2 G726-32/8000 a=sendrecv Asterisk->GW (Call 1) SIP/2.0 100 Trying Asterisk->GW (Call 2) INVITE sip:0xxxxxxx@192.168.1.156 SIP/2.0 From: "0yyyyyyy" <sip:0yyyyyyy@172.16.0.26>;tag=as12435432 To: <sip:0xxxxxxx@192.168.1.156> Content-Type: application/sdp Content-Length: 227 v=0 o=root 1899 1899 IN IP4 172.16.0.26 s=session c=IN IP4 172.16.0.26 t=0 0 m=audio 30004 RTP/AVP 0 3 8 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv GW->Asterisk (Call 2) SIP/2.0 100 Trying GW->Asterisk (Call 2) SIP/2.0 180 Ringing From: "0yyyyyyy" <sip:0yyyyyyy@172.16.0.26>;tag=as12435432 To: <sip:0xxxxxxx@192.168.1.156>;tag=-352630980 Content-Length: 0 Asterisk->GW (Call 1) SIP/2.0 180 Ringing From: <sip:0yyyyyyy@172.16.0.26>;tag=-115824375 To: <sip:0xxxxxxx@172.16.0.26>;tag=as30f5ada3 Content-Length: 0 Asterisk->GW (Call 1) SIP/2.0 183 Session Progress From: <sip:0yyyyyyy@172.16.0.26>;tag=-115824375 To: <sip:0xxxxxxx@172.16.0.26>;tag=as30f5ada3 Content-Type: application/sdp Content-Length: 204 v=0 o=root 1899 1899 IN IP4 172.16.0.26 s=session c=IN IP4 172.16.0.26 t=0 0 m=audio 30002 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv ------ now RTP Stream for Call 1 ------ GW->Asterisk (Call 2) SIP/2.0 200 OK From: "0yyyyyyy" <sip:0yyyyyyy@172.16.0.26>;tag=as12435432 To: <sip:0xxxxxxx@192.168.1.156>;tag=-352630980 Content-Type: application/sdp Content-Length: 148 v=0 o=- 1185978979 1185978980 IN IP4 192.168.1.156 s=- c=IN IP4 192.168.1.156 t=0 0 m=audio 40032 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv Asterisk->GW (Call 2) ACK sip:0xxxxxxx@192.168.1.156:5060 SIP/2.0 From: "0yyyyyyy" <sip:0yyyyyyy@172.16.0.26>;tag=as12435432 To: <sip:0xxxxxxx@192.168.1.156>;tag=-352630980 Contact: <sip:0yyyyyyy@172.16.0.26> Content-Length: 0 Asterisk->GW (Call 1) SIP/2.0 200 OK From: <sip:0yyyyyyy@172.16.0.26>;tag=-115824375 To: <sip:0xxxxxxx@172.16.0.26>;tag=as30f5ada3 Content-Length: 204 v=0 o=root 1899 1900 IN IP4 172.16.0.26 s=session c=IN IP4 172.16.0.26 t=0 0 m=audio 30002 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv GW->Asterisk (Call 1) ACK sip:0xxxxxxx@172.16.0.26 SIP/2.0 From: <sip:0yyyyyyy@172.16.0.26>;tag=-115824375 To: <sip:0xxxxxxx@172.16.0.26>;tag=as30f5ada3 Content-Length: 0 ------ here begin the problem the RTP stream for call 2 from Astrisk begin with the RTP Timestamp from Call 1 and the RTP Stream for Call 1 uses the next Sequence Number but the RTP Timestamp is 0 ****** ADDITIONAL INFORMATION ****** extensinoins.conf (only call forwarding) [test] exten => _X.,1,Dial(SIP/${EXTEN}@gw, 120, t) exten => h,1,Hangup() sip.conf [general] progressinband=yes [gw] context=test host=dynamic type=friend nat=no canreinvite=no | ||
Comments: | By: Joshua C. Colp (jcolp) 2007-08-01 09:57:07 Console output and rtp debug is needed. But if it is doing a packet2packet bridge then this is correct as the marker bit gets set initially to indicate a new source. By: wdecarne (wdecarne) 2007-08-01 10:15:20 I see in the rtp stream no marker and i wonder that the rtp stream from the second call become the timestamp from the first call. By: wdecarne (wdecarne) 2007-08-02 06:37:27 Okay, i understood the behavior with the timestamp from call 1 and call 2 and the forwarding from the rtp stream. I read the RFC3551 about the use of the marker bit and i found this: RFC3551: "Applications without silence suppression MUST set the marker bit to zero." In this application is no silence suppression. By: Joshua C. Colp (jcolp) 2007-08-03 09:40:42 Oh I see what you mean... the RTP stack is passing through the timestamp for jitterbuffer purposes on the remote end. Is this actually causing an issue? By: wdecarne (wdecarne) 2007-08-03 10:19:31 Yes, one point is that the calculation for the jitterbuffer is incorrect. But an other point is, that a codec from AudioCodes play no audio for a few seconds. I think the codec is waiting for the following timestamp from the rtp stream with the calling tone and at this time the caller can't hear the callee for a few seconds and this after the 200 respond. It works fine when the progressinband is disable or silence suppression in the codecs is enable (while the marker bit is use). By: Digium Subversion (svnbot) 2007-08-06 10:09:51 Repository: asterisk Revision: 78172 ------------------------------------------------------------------------ r78172 | file | 2007-08-06 10:09:50 -0500 (Mon, 06 Aug 2007) | 4 lines (closes issue ASTERISK-10000) Reported by: wdecarne Now that we pass through RTP timestamp information we need to make the allowed timestamp skew considerably less. There are situations where a source may change and due to the timestamp difference the receiver will experience an audio gap since we did not indicate by setting the marker bit that the source changed. ------------------------------------------------------------------------ By: Digium Subversion (svnbot) 2007-08-06 10:10:56 Repository: asterisk Revision: 78173 ------------------------------------------------------------------------ r78173 | file | 2007-08-06 10:10:56 -0500 (Mon, 06 Aug 2007) | 12 lines Merged revisions 78172 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r78172 | file | 2007-08-06 12:27:24 -0300 (Mon, 06 Aug 2007) | 4 lines (closes issue ASTERISK-10000) Reported by: wdecarne Now that we pass through RTP timestamp information we need to make the allowed timestamp skew considerably less. There are situations where a source may change and due to the timestamp difference the receiver will experience an audio gap since we did not indicate by setting the marker bit that the source changed. ........ ------------------------------------------------------------------------ By: Digium Subversion (svnbot) 2007-08-22 10:56:42 Repository: asterisk Revision: 80255 ------------------------------------------------------------------------ r80255 | file | 2007-08-22 10:56:41 -0500 (Wed, 22 Aug 2007) | 4 lines (closes issue ASTERISK-10141) Reported by: sinistermidget Revert commit from issue ASTERISK-10000 and return timestamp skew to 640. ------------------------------------------------------------------------ By: Digium Subversion (svnbot) 2007-08-22 10:58:02 Repository: asterisk Revision: 80256 ------------------------------------------------------------------------ r80256 | file | 2007-08-22 10:58:02 -0500 (Wed, 22 Aug 2007) | 12 lines Merged revisions 80255 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r80255 | file | 2007-08-22 13:14:38 -0300 (Wed, 22 Aug 2007) | 4 lines (closes issue ASTERISK-10141) Reported by: sinistermidget Revert commit from issue ASTERISK-10000 and return timestamp skew to 640. ........ ------------------------------------------------------------------------ By: Olle Johansson (oej) 2007-11-06 02:30:47.000-0600 Any updates on this issue? By: Joshua C. Colp (jcolp) 2008-02-25 12:40:34.000-0600 Please give the attached patch a go. By: Digium Subversion (svnbot) 2008-03-04 12:01:58.000-0600 Repository: asterisk Revision: 105674 U branches/1.4/channels/chan_sip.c U branches/1.4/include/asterisk/rtp.h U branches/1.4/main/rtp.c ------------------------------------------------------------------------ r105674 | file | 2008-03-04 12:01:46 -0600 (Tue, 04 Mar 2008) | 8 lines When a new source of audio comes in (such as music on hold) make sure the marker bit gets set. (closes issue ASTERISK-10000) Reported by: wdecarne Patches: 10355.diff uploaded by file (license 11) (closes issue ASTERISK-10992) Reported by: kanderson ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=105674 By: Digium Subversion (svnbot) 2008-03-04 12:05:23.000-0600 Repository: asterisk Revision: 105675 _U trunk/ U trunk/channels/chan_sip.c U trunk/include/asterisk/rtp.h U trunk/main/rtp.c ------------------------------------------------------------------------ r105675 | file | 2008-03-04 12:05:15 -0600 (Tue, 04 Mar 2008) | 16 lines Merged revisions 105674 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105674 | file | 2008-03-04 14:05:28 -0400 (Tue, 04 Mar 2008) | 8 lines When a new source of audio comes in (such as music on hold) make sure the marker bit gets set. (closes issue ASTERISK-10000) Reported by: wdecarne Patches: 10355.diff uploaded by file (license 11) (closes issue ASTERISK-10992) Reported by: kanderson ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=105675 By: Digium Subversion (svnbot) 2008-03-04 12:51:42.000-0600 Repository: asterisk Revision: 105728 _U team/murf/bug6002/ U team/murf/bug6002/CHANGES U team/murf/bug6002/channels/chan_local.c U team/murf/bug6002/channels/chan_sip.c U team/murf/bug6002/channels/chan_zap.c U team/murf/bug6002/funcs/func_version.c U team/murf/bug6002/include/asterisk/_private.h U team/murf/bug6002/include/asterisk/rtp.h U team/murf/bug6002/main/asterisk.c U team/murf/bug6002/main/autoservice.c U team/murf/bug6002/main/channel.c U team/murf/bug6002/main/hashtab.c U team/murf/bug6002/main/pbx.c U team/murf/bug6002/main/rtp.c U team/murf/bug6002/res/snmp/agent.c ------------------------------------------------------------------------ r105728 | murf | 2008-03-04 12:51:34 -0600 (Tue, 04 Mar 2008) | 228 lines Merged revisions 105558,105561,105564,105566,105569,105571,105573-105574,105589-105590,105592-105595,105597,105675,105677 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r105558 | file | 2008-03-03 08:16:57 -0700 (Mon, 03 Mar 2008) | 14 lines Merged revisions 105557 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105557 | file | 2008-03-03 11:15:39 -0400 (Mon, 03 Mar 2008) | 6 lines Add a comment to describe some logic. (closes issue ASTERISK-11558) Reported by: flefoll Patches: chan_sip.c.br14.patch-just-a-comment uploaded by flefoll (license 244) ........ ................ r105561 | file | 2008-03-03 08:30:29 -0700 (Mon, 03 Mar 2008) | 15 lines Merged revisions 105560 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105560 | file | 2008-03-03 11:28:59 -0400 (Mon, 03 Mar 2008) | 7 lines It is possible for no audio to pass between the current digit and next digit so expand logic that clears emulation to AST_FRAME_NULL. (closes issue ASTERISK-11364) Reported by: edgreenberg Patches: v1-11911.patch uploaded by dimas (license 88) Tested by: tbsky ........ ................ r105564 | russell | 2008-03-03 08:59:50 -0700 (Mon, 03 Mar 2008) | 40 lines 3) In addition to merging the changes below, change trunk back to a regular LIST instead of an RWLIST. The way this list works makes it such that a RWLIST provides no additional benefit. Also, a mutex is needed for use with the thread condition. Merged revisions 105563 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105563 | russell | 2008-03-03 09:50:43 -0600 (Mon, 03 Mar 2008) | 24 lines Merge in some changes from team/russell/autoservice-nochans-1.4 These changes fix up some dubious code that I came across while auditing what happens in the autoservice thread when there are no channels currently in autoservice. 1) Change it so that autoservice thread doesn't keep looping around calling ast_waitfor_n() on 0 channels twice a second. Instead, use a thread condition so that the thread properly goes to sleep and does not wake up until a channel is put into autoservice. This actually fixes an interesting bug, as well. If the autoservice thread is already running (almost always is the case), then when the thread goes from having 0 channels to have 1 channel to autoservice, that channel would have to wait for up to 1/2 of a second to have the first frame read from it. 2) Fix up the code in ast_waitfor_nandfds() for when it gets called with no channels and no fds to poll() on, such as was the case with the previous code for the autoservice thread. In this case, the code would call alloca(0), and pass the result as the first argument to poll(). In this case, the 2nd argument to poll() specified that there were no fds, so this invalid pointer shouldn't actually get dereferenced, but, this code makes it explicit and ensures the pointers are NULL unless we have valid data to put there. (related to issue ASTERISK-11555) ........ ................ r105566 | russell | 2008-03-03 09:02:19 -0700 (Mon, 03 Mar 2008) | 11 lines Merged revisions 105565 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105565 | russell | 2008-03-03 10:01:50 -0600 (Mon, 03 Mar 2008) | 3 lines Update the copyright information for autoservice. Most of the code in this file now is stuff that I have written recently ... ........ ................ r105569 | russell | 2008-03-03 10:06:35 -0700 (Mon, 03 Mar 2008) | 11 lines Merged revisions 105568 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105568 | russell | 2008-03-03 11:05:16 -0600 (Mon, 03 Mar 2008) | 3 lines Fix a potential memory leak of the local_pvt struct when ast_channel allocation fails. Also, in passing, centralize the code necessary to destroy a local_pvt. ........ ................ r105571 | russell | 2008-03-03 10:17:27 -0700 (Mon, 03 Mar 2008) | 11 lines Merged revisions 105570 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105570 | russell | 2008-03-03 11:16:53 -0600 (Mon, 03 Mar 2008) | 3 lines In the case of an ast_channel allocation failure, take the local_pvt out of the pvt list before destroying it. ........ ................ r105573 | qwell | 2008-03-03 11:08:05 -0700 (Mon, 03 Mar 2008) | 15 lines Merged revisions 105572 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105572 | qwell | 2008-03-03 12:06:52 -0600 (Mon, 03 Mar 2008) | 7 lines Fix types for astNumChannels and astConfigCallsProcessed. (closes issue ASTERISK-11553) Reported by: jeffg Patches: 12114.patch uploaded by jeffg (license 192) ........ ................ r105574 | russell | 2008-03-03 11:49:34 -0700 (Mon, 03 Mar 2008) | 4 lines Fix some code that was improperly changed in revision 104866 from issue ASTERISK-11520. (closes issue ASTERISK-11566, reported by elguero, patched by me) ................ r105589 | russell | 2008-03-03 21:26:39 -0700 (Mon, 03 Mar 2008) | 3 lines Use ast_copy_string() instead of strncpy(), and use sizeof() instead of a magic number ................ r105590 | russell | 2008-03-03 21:28:48 -0700 (Mon, 03 Mar 2008) | 3 lines - Add curly braces around the while loop - Properly break out of the loop on error when an included context is not found ................ r105592 | russell | 2008-03-03 21:31:53 -0700 (Mon, 03 Mar 2008) | 11 lines Blocked revisions 105591 via svnmerge ........ r105591 | russell | 2008-03-03 22:31:29 -0600 (Mon, 03 Mar 2008) | 4 lines Backport a minor bug fix from trunk that I found while doing random code cleanup. Properly break out of the loop when a context isn't found when verify that includes are valid. ........ ................ r105593 | russell | 2008-03-03 21:44:28 -0700 (Mon, 03 Mar 2008) | 2 lines remove unnecessary casts ................ r105594 | russell | 2008-03-03 21:47:32 -0700 (Mon, 03 Mar 2008) | 2 lines Make it so you don't have to cast away const in a couple places ................ r105595 | russell | 2008-03-03 21:57:29 -0700 (Mon, 03 Mar 2008) | 2 lines Simplify a trivial snprintf() with ast_copy_string() ................ r105597 | russell | 2008-03-04 09:55:17 -0700 (Tue, 04 Mar 2008) | 2 lines Update CHANGES heading ................ r105675 | file | 2008-03-04 11:08:42 -0700 (Tue, 04 Mar 2008) | 16 lines Merged revisions 105674 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105674 | file | 2008-03-04 14:05:28 -0400 (Tue, 04 Mar 2008) | 8 lines When a new source of audio comes in (such as music on hold) make sure the marker bit gets set. (closes issue ASTERISK-10000) Reported by: wdecarne Patches: 10355.diff uploaded by file (license 11) (closes issue ASTERISK-10992) Reported by: kanderson ........ ................ r105677 | file | 2008-03-04 11:11:38 -0700 (Tue, 04 Mar 2008) | 10 lines Merged revisions 105676 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105676 | file | 2008-03-04 14:10:34 -0400 (Tue, 04 Mar 2008) | 2 lines In addition to setting the marker bit let's change our ssrc so they know for sure it is a different source. ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=105728 By: Digium Subversion (svnbot) 2008-03-05 18:03:35.000-0600 Repository: asterisk Revision: 106299 _U branches/1.6.0/ U branches/1.6.0/channels/chan_sip.c U branches/1.6.0/include/asterisk/rtp.h U branches/1.6.0/main/rtp.c ------------------------------------------------------------------------ r106299 | russell | 2008-03-05 18:03:32 -0600 (Wed, 05 Mar 2008) | 24 lines Merged revisions 105675 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r105675 | file | 2008-03-04 12:08:42 -0600 (Tue, 04 Mar 2008) | 16 lines Merged revisions 105674 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105674 | file | 2008-03-04 14:05:28 -0400 (Tue, 04 Mar 2008) | 8 lines When a new source of audio comes in (such as music on hold) make sure the marker bit gets set. (closes issue ASTERISK-10000) Reported by: wdecarne Patches: 10355.diff uploaded by file (license 11) (closes issue ASTERISK-10992) Reported by: kanderson ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=106299 |