[asterisk-dev] Sip -> Zap(ETSI-ISDN) always generates 183 with SDP ?

[Peter Childs]

gday guys (n'gals).

I have a third party SIP platform which generates outbound calls via
asterisk to ISDN (Australia - so thats ETSI ISDN).   This platform doesn't
really like inband signalling on outbound calls (ie getting 183's with SDP
-- its fine with 180 Ringing etc...)

Having had a bit of a silly time with the sip.conf variable
progressinband=never,no,yes (arg!) I dug a little deeper into the chan_sip
code.

It appears on a SIP->Zap call the ISDN channel is opened, and before you can
say 'boo' sip_write() in chan_sip is called.... this appears to occurs prior
to any ISDN signalling (such as PRI_EVENT_PROCEEDING etc..)

sip_write doesn't seem to care at all what progressinband is set to, and if
it gets a frame when the SIP channel is not in AST_STATE_UP it generates a
183 with SDP (then sets SIP_PROGRESS_SENT)

Does this behaviour seem strange?   I'm not really sure if this is a bug, a
'its just like that' thing, or something strange with our ISDN that is
unusual?

In an ideal world (for me anyway... *grin*) I would think that
progressinband=never (or even progressinband=no) would mean that 180
Ringing, 486 Busy etc would be used and 183 Session Progress with SDP would
not...

I have done some basic testing and if I patch as follows...

--start patch--

*** chan_sip.c.orig     2006-05-03 15:26:28.000000000 +1000
--- chan_sip.c  2006-05-03 19:59:04.000000000 +1000
***************
*** 2548,2555 ****
                        if (p->rtp) {
                                /* If channel is not up, activate early
media session */
                                if ((ast->_state != AST_STATE_UP) &&
!ast_test_flag(p, SIP_PROGRESS_SENT) && !ast_test_flag(p, SIP_OUTGOING)) {
!                                       transmit_response_with_sdp(p, "183
Session Progress", &p->initreq, 0);
!                                       ast_set_flag(p, SIP_PROGRESS_SENT);
                                }
                                time(&p->lastrtptx);
                                res =  ast_rtp_write(p->rtp, frame);
--- 2548,2566 ----
                        if (p->rtp) {
                                /* If channel is not up, activate early
media session */
                                if ((ast->_state != AST_STATE_UP) &&
!ast_test_flag(p, SIP_PROGRESS_SENT) && !ast_test_flag(p, SIP_OUTGOING)) {
!                                       /* We have found that on outbound
ISDN calls via zap               */
!                                       /* frames start heading for SIP
before any signalling from         */
!                                       /* the ISDN -- if progressinband=yes
then do early media otherwise */
!                                       /* supress the 183 Session Progress
with SDP                       */
!
!                                       if(ast_test_flag(p,SIP_PROG_INBAND)
== SIP_PROG_INBAND_YES) {
!
transmit_response_with_sdp(p, "183 Session Progress", &p->initreq, 0);
!                                               ast_set_flag(p,
SIP_PROGRESS_SENT);
!                                       } else {
!                                               //ast_log(LOG_WARNING, "
***PJC*** Supress Early Media Frame\n" );
!                                               ast_mutex_unlock(&p->lock);
!                                               return 0;
!                                       }
                                }
                                time(&p->lastrtptx);
                                res =  ast_rtp_write(p->rtp, frame);

--end patch--

then I don't see the 183 Session Progress with SDP, and things 'appear' to
go ok for my basic calls, however I see a good splash of these type of
messages when the call goes from RINGING to UP...

May  3 19:22:22 DEBUG[12005] chan_zap.c: Write returned -1 (Resource
temporarily unavailable) on channel 1

I guess I'm not sure if this is a bug, a 'feature', or a limitation.

Any help or pointers would be great.  I'm happy to bugs.digium.com it, but I
wanted to make sure I wasn't wasting anyones time.

For what its worth I'm using a plain Dial() (no 'r'), progressinband=never,
and the latest 1.2 from SVN for this testing.

Cheers,
  Peter


--
 Peter Childs
 NEC Business Solutions Ltd
 Ph:61-8-8301-4908 Mb:61-4-0819-7693
 IM: pjcinaus (yahoo)