[Asterisk-Dev] SIP Early Media in Asterisk

[Casey Lee]

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