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

[Gianluca Merlo]

Hello,

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

Best regards

Gianluca