[asterisk-dev] SIP/TDM interworking, and RTP on CALL PROCEEDING

[Eric Wieling]

-----Original Message-----
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) 
>> interworking,
>
>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 1.8.19.1
 - 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 
>> inconvenience.
>> 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
>> doubts)
>> for the sake of brevity, hoping you can follow the main lines in my 
>> reasoning.
>
>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