[asterisk-dev] SIP/TDM interworking, and RTP on CALL PROCEEDING
EWieling at nyigc.com
Sat Feb 16 15:59:37 CST 2013
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Gianluca Merlo
Sent: Saturday, February 16, 2013 3:37 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] SIP/TDM interworking, and RTP on CALL PROCEEDING
On Fri, Feb 15, 2013 at 08:30:04PM -0600, Richard Mudgett wrote:
>> I thought of posting my question in this mailing list (as opposed to
>> asterisk-users) because I think it is more technical and related to
>> Asterisk's inner workings than a typical user question. I apologize
>> in advance if it is misplaced.
>> I use Asterisk (1.8) in scenarios which involve SIP/TDM (E1 PRI)
>Since you did not specify which version of 1.8, I hope you are not
>using v1.8.7. The ./configure script in that version does not setup
>Asterisk to use libpri correctly.
I am observing the problem on a system with
- Asterisk 18.104.22.168
- DAHDI 2.6.1
- libpri 1.4.14 (also tried with 1.4.13)
>> and recently I stumbled on an interesting fact which is causing some
>> While placing calls from SIP on DAHDI, I noticed that Asterisk
>> apparently sends RTP right after receiving a CALL PROCEEDING Q.931
>> message, even if this does not include any progress indication
>> suggesting that there may be inband progress information. All the RTP
>> packets are sent with the marker set, up until Asterisk receives some
>> relevant progress information (PROGRESS/ALERTING with progress
>> indication 1 or 8).
>> I seem to understand that this behaviour is known, judging by the
>> "prematuremedia" option in sip.conf, but as the documentation of this
>> option states, what is currently possible (setting the option to
>> "no") is to put the call "in progress" and anticipate the SIP 183
>> response, not preventing Asterisk to send media before some "more
>> proper" progress indication. This is however not a feasible solution,
>> because in my use-case CALL PROCEEDING gets signalled almost
>> immediately, and progress is carried by a "pure" ALERTING without
>> inband indication (and indeed, without any inband progress
>> information) and sending SIP 183 seems to make all the devices I have
>> tested playback the silence/"garbage" they receive with the RTP
>> "ignoring" the SIP 180 generated by the ALERTING.
>> If you think that this may not be considered a bug, may I ask you a
>> little help on how this may be obtained by a patch? My study of
>> Asterisk's source code is sadly still in very early stages, and I am
>> having some trouble tracing back the point in which "the media path
>> gets opened". I confess that my current understanding does not even
>> include (pardon any miswording here) notions about how and when voice
>> frames start being read from TDM, and if this is preventable at all.
>> If you feel the issue or my case in general is beyond hope, or would
>> like to point out some documentation to help me, I offer you my
>> earnest thanks in advance. Also, I apologize for any incorrectness in
>> the technical matters exposed, which I tried to leave "vague" (and
>> thus prone to remarks or
>> for the sake of brevity, hoping you can follow the main lines in my
>I would like to see a "pri set debug on span x" trace of the call.
I am attaching what I hope is enough. The debug is actually "intense", and I overwrote references to actual numbers. In this call, which is made to a test destination, CALL PROCEEDING and further progress informations are purposely separated by 5 seconds of wait. The RTP flow seems to start after the PRI_EVENT_PROCEEDING gets indicated on the SIP channel, and the corresponding
100 Trying gets sent.
configs/sip.conf.sample has this to say:
;prematuremedia=no ; Some ISDN links send empty media frames before
; the call is in ringing or progress state. The SIP
; channel will then send 183 indicating early media
; which will be empty - thus users get no ring signal.
; Setting this to "yes" will stop any media before we have
; call progress (meaning the SIP channel will not send 183 Session
; Progress for early media). Default is "yes". Also make sure that
; the SIP peer is configured with progressinband=never.
; In order for "noanswer" applications to work, you need to run
; the progress() application in the priority before the app.
;progressinband=never ; If we should generate in-band ringing always
; use 'never' to never use in-band signalling, even in cases
; where some buggy devices might not render it
; Valid values: yes, no, never Default: never
More information about the asterisk-dev