asterisk users - Dec 2009 - E1 ingress to SIP egress problem with 183 response

Hi,

I've looked around the archives and have spent a while on voip-info.org
but not found an answer so forgive me if this is in a FAQ somewhere.

We've got several Asterisk servers with E1 cards (some Digium, some
Sangoma). We provide non geographic numbers for customers and route
calls to their existing phone numbers. Calls come in over the PSTN and
into Asterisk.

This works perfectly if we route calls out via the PSTN but it is
expensive, so we have been trying a different carrier where we egress to
them using SIP and let them break out to the PSTN at their end. However,
when using the SIP carrier, we've had complaints that the caller hears
the remote phone ring for about 15 seconds and if unanswered at this
point, the line hangs up.

The problem seems to be that when the remote phone starts ringing (the
caller can hear the ringing sound) the SIP carrier is sending back a 183
Session Progress SIP message but Asterisk isn't changing the state of
the incoming E1 channel to indicate this. If the called party doesn't
answer within 15 - 20 seconds, the calling equipment assumes that the
line is dead and requests a hangup.

If the called party answers the phone quite quickly, everything works.

If I route out to a different SIP gateway that sends a 180 Ringing back,
then this is OK - the call can ring for a long time and not cut off.
After the 180 Ringing message comes back, the incoming E1 gets a state
change to Call Received:

logger.c: q931.c:2802 q931_alerting: call 16123 on channel 2 enters state 7
(Call Received)

However when we only get a 183 back, this doesn't happen and is causing
us a problem.

I would prefer to solve the problem by changing a configuration option
somewhere but I'm running out of ideas.

I've had a look in chan_sip.c and have seen this:

        case 180:       /* 180 Ringing */
        case 182:       /* 182 Queued */
                if (!ast_test_flag(req, SIP_PKT_IGNORE) &&
(p->invitestate != INV_CANCELLED) && sip_cancel_destroy(p))
                        ast_log(LOG_WARNING, "Unable to cancel SIP
destruction.  Expect bad things.\n");
                if (!ast_test_flag(req, SIP_PKT_IGNORE) && p->owner)
{
                        ast_queue_control(p->owner, AST_CONTROL_RINGING);
                        if (p->owner->_state != AST_STATE_UP) {
                                ast_setstate(p->owner, AST_STATE_RINGING);
                        }
                }
                if (find_sdp(req)) {
                        if (p->invitestate != INV_CANCELLED)
                                p->invitestate = INV_EARLY_MEDIA;
                        res = process_sdp(p, req);
                        if (!ast_test_flag(req, SIP_PKT_IGNORE) &&
p->owner) {
                                /* Queue a progress frame only if we have SDP in
180 or 182 */
                                ast_queue_control(p->owner,
AST_CONTROL_PROGRESS);
                        }
                }
                check_pendings(p);
                break;

        case 183:       /* Session progress */
                if (!ast_test_flag(req, SIP_PKT_IGNORE) &&
(p->invitestate != INV_CANCELLED) && sip_cancel_destroy(p))
                        ast_log(LOG_WARNING, "Unable to cancel SIP
destruction.  Expect bad things.\n");
                /* Ignore 183 Session progress without SDP */
                if (find_sdp(req)) {
                        if (p->invitestate != INV_CANCELLED)
                                p->invitestate = INV_EARLY_MEDIA;
                        res = process_sdp(p, req);
                        if (!ast_test_flag(req, SIP_PKT_IGNORE) &&
p->owner) {
                                /* Queue a progress frame */
                                ast_queue_control(p->owner,
AST_CONTROL_PROGRESS);
                        }
                }
                check_pendings(p);
                break;


I wondered if I made case 183 be the same as cases 180 and 182 whether
it would solve this problem and if so, whether that would be OK or
whether it might cause other problems.

Or is there a better way to make it work with a 183 response?


For testing, if I specify the "r" option to the Dial command to tell
Asterisk to generate its own ringing tone, this solves the hangup
problem as well, though we can't use this option because of the other
potentially useful tones it masks. When using the "r" option, we get
these Q.931 log entries:

logger.c: q931.c:3509 q931_receive: call 22267 on channel 27 enters state 6
(Call Present)
logger.c: q931.c:2774 q931_call_proceeding: call 22267 on channel 27 enters
state 9 (Incoming Call Proceeding)

This is on Asterisk 1.4.22.

-- 
Cheers,
Kingsley.