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

[Gianluca Merlo]

On Thu, Feb 21, 2013 at 12:52:13PM -0600, Richard Mudgett wrote:
>> I am sorry for the delay in providing a feedback, which is due to the
>> tests I
>> have made on this matter.
>> 
>> Unfortunately, your suggestion does affect the behaviour of Asterisk
>> upon
>> receiving PROGRESS, and in the test scenario we are discussing this
>> only leads
>> to having the SIP 183 delayed until an ALERTING with progress
>> indicator 8 comes
>> in. The RTP sent after call proceeding is not affected by this
>> modification.
>> 
>> As I said, not to bother you too much, and following my initial
>> research path,
>> I went back with the help of a friend and colleague to verify the
>> part of the
>> code you pointed out in your patch, and more specifically the
>> handling of
>> PRI_EVENT_PROCEEDING immediately after the part you suggested to
>> patch.
>> After some trial and error, I seem to trace the origin of the
>> behaviour to the
>> call to sig_pri_set_dialing(), which is performed right before
>> sig_pri_unlock_private() and breaking out of the case statement
>> (channels/sig_pri.c:5671 in 1.8.19.1). It seems that the "dialing"
>> member of
>> the DAHDI private struct (which is set to 0 by this call) affects
>> subsequent
>> calls to dahdi_read(), leading it to return voice frames when it
>> (imho) should
>> not, which in turn get sent over to the SIP channel.
>> 
>> Apart from this description, I hope that you can answer some
>> questions
>> regarding these parameters and calls:
>> 
>>  - What is the expected role of the "dialing" dahdi private struct
>>  member? Are
>>    my assumptions, by your advice, correct?
>
>For sig_pri that flag is really a Rx squelch.  The flag originally
>comes from POTS support for when the line is dialing.  Even there I
>think it was really for Rx squelch.  It is poorly named.
>
>>  - I see that apparently calls to sig_pri_set_dialing() like the one
>>  I am
>>    supposing as the origin of my issue generally come when you call
>>    sig_pri_open_media() and when there is a progress indication which
>>    suggests
>>    that inband information is available on the channel. You
>>    explicitly comment
>>    many parts like these in the code with the comment "Bring voice
>>    path up". Is
>>    it correct that the handling of PRI_EVENT_PROCEEDING is seemingly
>>    the only
>>    exception, having a call to sig_pri_set_dialing() irregardless of
>>    the
>>    presence of a progress indication in Q.931 signalling, and of a
>>    call to
>>    sig_pri_open_media()?
>
>Yes and it is because of the issue you point out next.
>
>>  - This is partly related to my previous question, but is it correct
>>  that all
>>    this is related to the issue in:
>> 
>>    https://issues.asterisk.org/jira/browse/ASTERISK-17834
>> 
>>    and that it seems that the call to sig_pri_set_dialing() was moved
>>    to be
>>    made even without a proper progress indication (and a call to
>>    sig_pri_open_media()) to accomodate the scenario in this issue?
>
>Yes, you are correct in your analysis.  If you move the line back to
>before the sig_pri_open_media() call does it clear up your issue?
>
>Further history is with ASTERISK-12346 where the dialing flag was
>originally misplaced in the provided patch that was committed.
>
>Q.931 Section 5.1.2 says when we should attach in this paragraph:
>
>  "The user need not attach until receiving a CALL PROCEEDING/SETUP
>  ACKNOWLEDGE/PROGRESS/ALERTING message with the progress indicator
>  No. 8, in-band information or appropriate pattern is now available,
>  or progress indicator No. 1, call is not end-to-end ISDN; further
>  call progress information may be available in-band. Prior to this
>  time, the network cannot assume that the user has attached to the
>  B-channel. After this time, the user shall be connected to the
>  B-channel, provided the equipment does not generate local tone.
>  Upon receipt of the CONNECT message, the user shall attach to the
>  B-channel (if it has not already done so)."
>
>I am now thinking ASTERISK-17834 was really to accommodate a broken peer
>and should have been handled as a config option instead.  I think
>an option like force_early_media with a chan_dahdi.conf.sample
>description saying that in-band information is assumed when a
>PROCEEDING message is received.
>
>Please create a JIRA issue for this.
>
>Thanks.
>
>Richard

Hello Richard,

thanks for your assistance. I confirm that moving back the call to
sig_pri_set_dialing() restores the behaviour I expected. I opened
ASTERISK-21151

 https://issues.asterisk.org/jira/browse/ASTERISK-21151

for more systematic considerations and inclusion in Asterisk.

Best regards

Gianluca