SIP r&d (asterisk,ser,yate)

//*If the following text is garbled or unreadable, there is a ms-word file attached with the same content to this project*//



Carrier 'SIP' asterisk 1.2.4 'SIP' sipura-spa3000 'FXO'PSTN


Carrier 'SIP' asterisk 1.2.4 'SIP' grandstream ht488 'FXO'PSTN


Carrier 'SIP' asterisk 1.2.4 'SIP' [Any other single SIP FXO port] 'FXO'PSTN


FAS on asterisk ' spa3000 call leg

In words:

Sipura/grandtream/clipcomm manufacture FXO sip gateways.

When placing a call from asterisk to any of the above FXO ports with this command in [url removed, login to view] -

Exten => _.,1,Dial(SIP/${EXTEN}@FXO-one_of_ht488_spa3000_CG410-FXO)

And using the FXO in single stage gateway mode (ie. The gateway accepts sip uri, versus providing dialtone and waiting for DTMF) the following occurs -

Asterisk FXO

1. -> INVITE ->

2. <- SIP 100 Trying <-

3. <- SIP 183 Session Progress <- [here FXO sends it's own ring back tone inside RTP]


When the call is bridged and billing has started, FXO starts to dial the ${EXTEN}.

Originating SIP UA hears 2 sets of ring back tones, one by FXO port another from PSTN.

Even if dialed PSTN number is BUSY, the "billsec" would equal delta from step 4 above until the calling party decides to hang up.

This situation is called Facility Added Signaling or False Answer Supervision in short FAS.


Best case scenario - Eliminate FAS completely and provide correct call progress indication to the calling party

Worst case scenario - Introduce a configurable delay after step 2 to minimize the duration of wrongfully billed minutes.

-Proposed Solutions

Best Case - We can't give any technical direction as to which sip stack or framework to use, but we can describe our optimal success this way: Something like asterisk or ser with media proxy listening in on RTP that comes from FXO after SIP 200 OK (call established message) and detects ringback tones inside the audio (at least g729A/B is required), once the ringback tones stop, the software must open regular bi directional RTP ports. Or maybe the software would use VAD (voice activity detection) to send SIP 200 OK (connected) and open RTP ports to both directions.


sipUA asterisk 3rdSIP FXO


2. <- SIP 100 <- SIP 100 <- SIP 100 Trying

3. <- SIP 100 <- SIP 100 <- SIP 183 Session Progress

4. <- SIP 183 <- SIP 183 <- SIP 200 OK (pass one way RTP audio from PSTN)

5. <- SIP 200 <- SIP 200 OK Dial(SIP/${EXTEN}@FXO||fas(5))

fas(seconds) being the additional dial() parameter.


sipUA asterisk FXO

1. -> INVITE -> INVITE ->

2. <- SIP 100 Trying <- SIP 100 Trying

3. <- SIP 100 Trying <- SIP 183 Session Progress

4. <- SIP 100 Trying <- SIP 200 OK

5. <- Continue to send SIP 100 Trying for fas(seconds) <-

6. <- SIP 200 OK _.,1,Dial(SIP/FXO||D({$EXTEN}))

According to asterisk docs and gurus, it should only bridge channels after the called peer picked up, dial tone detected and DTMF sent. But it doesn't work. Period. Short of changing chan_sip.c nothing would help in this case.


If asterisk based solution - a patch that can be applied to current asterisk sources.

If your own software - Full source code and all rights are sole property of the client, that is us. You, as a developer renounce every eligibility to copy/modify/distribute or claim the software as your own doing. It's still OK, to have it on CV/resume and we would be very glad to provide references, but legally speaking, the code would belong to us and not the developer.

Compétences : Services audio, Programmation C, Linux, Administration Système

en voir plus : asterisk fas, asterisk false answer supervision, fxo gateway fas, asterisk exten dial fxo, asterisk false ring, fas asterisk, yate session progress, asterisk fas detection, sip open yate asterisk, ser versus yate, dial tone sip asterisk, asterisk 100 trying, false answering session asterisk, yate asterisk, asterisk 183 100, asterisk dial tone detection, grandstream fxo fas, false answer supervision solution, asterisk send sip session progress, yate sip regular uri

Concernant l'employeur :
( 1 commentaire ) Hong Kong, Hong Kong

Nº du projet : #46911