| Summary: | ASTERISK-02511: SIP Early Media Not Working | ||
| Reporter: | ruok (ruok) | Labels: | |
| Date Opened: | 2004-09-30 15:57:57 | Date Closed: | 2008-01-15 15:09:37.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) ata_to_excel_noearly_media.trace ( 1) console.log ( 2) debug.log ( 3) dialdiff.txt | |
| Description: | We have come across an issue with interfacing an Asterisk installation with a SIP to SS7 gateway, specifically in the area of early media. 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). 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. | ||
| Comments: | By: Brian West (bkw918) 2004-09-30 22:22:46 What does the RFC say? By: Brian West (bkw918) 2004-09-30 22:25:04 Also this wouldn't be considered a MAJOR bug since Asterisk does function. Major would be something that keeps the PBX from working such as a deadlock or crash. This is more of RFC compliance. By: Brian West (bkw918) 2004-09-30 22:25:58 Have you tried: progressinband=yes Not sure this would solve it but it might. By: Mark Spencer (markster) 2004-09-30 23:12:20 We already do send media in both directions before the call is up. This is irrespective of the progressinband setting. I suggest you look at the actual RTP traffic on the wire. By: ruok (ruok) 2004-09-30 23:32:11 We have an ethereal trace that shows the ata sending RTP to asterisk, and the MG sending RTP to asterisk, but asterisk is not sending RTP to either the ATA or the MG. Want me to post the trace? By: Mark Spencer (markster) 2004-10-01 00:03:09 It may more likely take someone logging in and looking. This setup is very common and is very widely used. Can you also provide the Dial line you are using? By: Mark Spencer (markster) 2004-10-01 09:52:34 a Full debug might also be helpful, i.e. running with asterisk -vvvgc and debug enabled in logger.conf. By: ruok (ruok) 2004-10-01 12:42:52 I have attached ata_to_excel_noearly_media.trace. It should be noted that we are using chan_sip2 for support of an outbound proxy. We tested this basic theory with regular chan_sip as well, with the same result. In this trace, 69.19.166.77 is the ATA IP, and 66.81.0.17 is the RTP port of the MG. The MG receives its signalling at the hostname smf-xl.sip.o1.com. The asterisk box is named smf-reg1.sip.o1.com. The outbound proxy for both the ATA and the MG is 66.81.0.87. There is a lot of other clutter on this network, but you can clearly see the ATA and the MG sending RTP to asterisk after the 183 message, but asterisk does not bridge the RTP until receipt of the 200 from the MG. The call-id from the ATA to asterisk is 64e0c8aa-775157ab The call-id for the second dialog from asterisk to the MG is 44e9a3a646e5ffce2b38ed7f4b660513 I have also uploaded console.log, which is the log from a -vvvvvvvvvvvgv, and debug.log, which is the logger debug level log file. We are also using ENUM, but you can see the Dial string used, which is a regular SIP dial string. I can provide you login access if you would like. I can be reached in real time almost any time today or this weekend via the following methods: tel: +1.916.730.5876 aim: RUok0101 icq: 1005866 msn: RUok0101@hotmail.com yahoo: RUok0101 jabber: mike@cheapnet.net By: ruok (ruok) 2004-10-07 11:18:17 Anyone get a chance to take a look at the debug info? I can make my system available to remote access if someone wants to login and check things out. By: ruok (ruok) 2004-10-07 11:52:09 I wanted to also add that in section 2.5 of RFC 3666 (Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows) it shows that a 183 should trigger two way RTP between the MG and the UAC. In this example, its because the UAC needs to hear the in-band treatment message, but the same applies to the above IVR example. By: Mark Spencer (markster) 2004-10-07 12:01:49 We generally do RTP bidirectionally on a 183. However, in your Dial incantation, you specifically added the "r" flag which means "generate ring only, and do not pass in-band audio", so you've explicitly turned it off. If you scroll back to my comments on 10/1/04, that's why i asked "Can you also provide the Dial line you are using." By: ruok (ruok) 2004-10-07 13:18:27 I posted the debug log, which contained the dial line. I thought you would have got it from there. This did fix the problem, thanks! However, since asterisk acks this way, and does not bridge the RTP through when using 'r', shouldn't asterisk provide ringing tone to the ATA after it sends a 183? The ATA stops providing local ring back to the user on recipt of the 183, so since RTP is not cut through, I would think it should at least continue to play ringing audio to the user, or else what is the logic behind only cutting media through when no 'r' is present. By: Mark Spencer (markster) 2004-10-07 14:29:00 Fair enough, fixed in CVS head. By: Russell Bryant (russell) 2004-10-07 22:49:20 fixed in the 1.0 branch By: Digium Subversion (svnbot) 2008-01-15 15:09:29.000-0600 Repository: asterisk Revision: 3934 U trunk/apps/app_dial.c ------------------------------------------------------------------------ r3934 | markster | 2008-01-15 15:09:29 -0600 (Tue, 15 Jan 2008) | 2 lines Do not send progress when "ringing" only flag is set (bug ASTERISK-2511) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=3934 By: Digium Subversion (svnbot) 2008-01-15 15:09:37.000-0600 Repository: asterisk Revision: 3944 U branches/v1-0/apps/app_dial.c ------------------------------------------------------------------------ r3944 | russell | 2008-01-15 15:09:37 -0600 (Tue, 15 Jan 2008) | 2 lines Do not send progress when "ringing" only flag is set (bug ASTERISK-2511) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=3944 | ||