Hello, We have come across an issue with interfacing an Asterisk installation with our SIP to SS7 gateway, specifically in the area of early media. We have read through Asterisk docs, mailing lists, source code, calling Digium and have attempted posting our question on mailing lists with no response. This problem is causing call failures in certain scenarios that I will explain shortly. The gist of the problem is that when Asterisk sends and INVITE to our gateway, and receives a 183 with SDP in the message body, not only should it send a 183 with Asterisk SDP to the ATA (which is correctly does now), but it should ALSO bridge the media path through, without showing the call as "answered" (and without starting CDR billing). Possible fix suggestion...maybe adding a new state that channel drivers can use, such as AST_STATE_EARLY_MEDIA, and on receipt of the 183 message, set the channel to this state. This way the channels can bridge together, but not have ast_cdr_answer() called, which starts billing for the call.
Now for some specifics, but first, here is how the network looks... ATA <---- SIP ----> Asterisk <---- SIP ----> Gateway <---- SS7 ----> PSTN * ATA - A sipura 2000 ATA. * Asterisk - Latest CVS distro on debian. * Gateway - The SIP to SS7 gateway is a product that we have developed internally. * PSTN - ISUP intermachine trunks to SBC The problem we have is that in many call scenarios originating from the ATA and terminating on the PSTN, interworking will occur between our PSTN peer (SBC) and the final call destination. For most calls, this interworking isn't a problem unless it is with a network that cannot signal call status out of band (i.e.. No way to signal "subscriber busy" other than playing a busy tone). In those cases, early media is REQUIRED to notify the calling party of call progress. Please check out RFC 3398 (Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping), section 5.5 (Early Media) for the recommendations on this. Here is a specific example of a problem. * ATA sends INVITE to Asterisk * Asterisk sends 100 to ATA * Asterisk sends INVITE to Gateway * Gateway sends 100 to Asterisk * Gateway sends IAM to SBC on PSTN (called number is DHL/Airborne Express 800-325-5555, serviced by AT&T) * SBC on PSTN sends IAM to AT&T * AT&T sends ACM to SBC * SBC sends ACM message to our gateway (This is the important part, we'll get to it later) * Gateway sends 183 with SDP to Asterisk AND begins forwarding media from PSTN to Asterisk RTP IP/Port * Asterisk sends 183 with SDP to ATA * ATA stops generating ringback on the analog phone, passes any media (which Asterisk is sending none of) to the phone and begins transmitting media to Asterisk Notice I never mentioned an ANM coming from the PSTN and a 200/ACK exchange. This is because AT&T does something sneaky here for it's IVR customers...they don't answer the phone until you get a real person! Instead they send CPG (call progress) messages in the backward direction every 30 seconds to keep the T9 timer from expiring. You call DHL's 800 number, and press buttons (1 for sales, 2 for support ...blah, blah) but as far as all the switches on the network are concerned, the call is still "ringing". So in this case, since Asterisk hasn't cut the media through yet, the person on the ATA hears dead air and the call eventually fails. They depend on the assumption that media is cut through at the "Ringing", not the "Answered" state. Although this may seem sneaky, it is legitimate per ANSI specification. Refer to ANSI T1.113-1995 (Signaling System No. 7 (SS7) - Integrated Services Digital Network (ISDN) User Part), Chapter 4 (Signaling Procedures), Section 2.1.4.3 (Receipt of Address Complete Message at the originating exchange) it states: "For a speech, 3.1 kHz audio, or UDI-TA call, the originating exchange shall through connect the transmission path in the backward direction, if not already connected. If the Address Complete Message indicates that interworking has occurred, the originating exchange shall through connect the transmission path in both directions, if not already connected." For the above mentioned call, there were three indicators in the ACM received from AT&T via SBC that this call should have been two-way through connected that caused our gateway to send the 183 with SDP to Asterisk...here are the indicators with the meaning after the '-': * Backward Call Indicator bit I was set - Interworking Encountered * Optional Backward Call Indicator bit A - Inband information or an appropriate pattern is now available * Optional Backward Call Indicator bit H - User-Network interaction occurs, cut through in both directions So to summarize, there are situations where calls MUST have their media cut through in the backward direction or in BOTH directions before the call is answered. Presently it appears that Asterisk is lacking this functionality in SIP to SIP calls and we also experience this problem in SIP to E&M channel associated signaling trunks. Is this problem something that is in the project roadmap to be resolved soon or will this just remain as a "known bug"? Thanks for your input, Casey Lee _______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
