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

[Richard Mudgett]

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

That trace is not intense.  It is decoding the Q.931 (layer 3) messages.
The intense trace is *only* needed when debugging Q.921 (layer 2) problems.
Otherwise, the intense trace just fills the log with unnecessary noise.

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

I think you may be confusing things.  The PRI_EVENT_PROCEEDING is
associated with the DAHDI channel not the SIP channel.  Messages
from different threads can come out delayed relative to when things
actually happen between threads.

The trace shows Asterisk receiving
PROCEEDING (with no progress indication ie)
wait 5 seconds
PROGRESS (with progress indication ie)
wait 5 seconds
ALERTING (with progress indication ie)

The PROCEEDING message will cause the SIP channel to send a
"100 Trying" message.  The SIP message should not have a SDP body.
The PROCEEDING message does not have a progress indication ie and
will not open the media path from the DAHDI channel.

The PROGRESS message will cause the SIP channel to send a
"183 Session Progress" message.  There should also be a SDP
body to open the RTP media path to the calling phone.  The
PROGRESS message *does* have a progress indication ie and *will*
open the media path from the DAHDI channel.

The ALERTING message may cause the SIP channel to send a
"180 Ringing" if it has not previously send a 183 message.
The ALERTING message also has a progress indication ie that would
open the media path from the DAHDI channel if it were not already
opened by the previous PROGRESS message.

This behavior would be expected from the messages in the trace.

Richard