[asterisk-dev] SIP/TDM interworking, and RTP on CALL PROCEEDING
rmudgett at digium.com
Thu Feb 21 12:52:13 CST 2013
> 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
> 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
> 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
> 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 18.104.22.168). It seems that the "dialing"
> member of
> the DAHDI private struct (which is set to 0 by this call) affects
> 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
> 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
> 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
> presence of a progress indication in Q.931 signalling, and of a
> call to
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:
> 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.
More information about the asterisk-dev