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

[Richard Mudgett]

> 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