[Home]

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:19Date Closed:2008-03-05 18:03:35.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents: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