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

Richard Mudgett rmudgett at digium.com
Fri Feb 15 20:30:04 CST 2013


> 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.

> 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.

Richard



More information about the asterisk-dev mailing list