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

[Gianluca Merlo]

On Sat, Feb 16, 2013 at 04:41:20PM -0600, Richard Mudgett wrote:
>> >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.

I'm sorry. I did not intend to do something not in your requests. It was not my
intention to make the log less readable, or make you spend more time in reading
unnecessary details.

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

I may, indeed, be confusing something. As I said I surely do not match your
expertise in the field, but I think that I was possibly misleading in my
explanation. What I meant to say, (I hope) more properly is that what I see
is:

 - CALL PROCEEDING coming on the DAHDI channel
 - 100 Trying on the SIP channel
 - RTP being sent immediately after this, and before any other
progress indication
   (being it PROGRESS, ALERTING, with relevant progress indication 1 or 8)

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

I can confirm that your description of what seen on the trace is flawless,
however, nonetheless it seems that the RTP flow starts right after the CALL
PROCEEDING, and before receiving other progress information. As I
said, this is what
I was not expecting. I thought (as you do, I think), that a CALL
PROCEEDING without
any progress indication 1 or 8 would lead to sending only a 100 Trying
on the SIP
channel, without leading to any media being sent.

In the end, I apologize in advance if I am the one misunderstanding the
expected behavior, and if my way of describing the situation is not proper or
clear. I hope that my explanations are clearer, and that you can confirm wheter
the sending of RTP this early (after CALL PROCEEDING, but before any progress
indication suggesting that media is available inband) is intentional. Also,
again thanks for all your help.

Best regards

Gianluca