How do you write an Asterisk Dialpan to suspend 180-Ringing until after 183-progress in chan_sip?

I'm trying to write an Asterisk dialplan to suspend 180-Ringing until after 183-progress. What needs to happen in the dialplan to prevent this?

Below you can see the trace: The chan_sip driver sends "180 Ringing" and then immediately get a 503 when the upstream trunk (next hop) sends a 503, but that upsets the carrier. They don't want to see ringing unless progress can be made so I want to suppress sending "180 Ringing" until after the upstream trunk sends a "183 Progress".

I looked at the Dial(SIP/117/X) function reference/flags but didn't see anything useful. This is chan_sip, but I would be open to chan_pjsip dialplan function calls or branch tests as well.

Ideas?

(FYI: This is a dialplan programming question, not a configuration question, so I think it belongs here on stackoverflow instead of superuser according to the SE asterisk tag rules.)

22:29:02.539741 IP (tos 0x68, ttl 57, id 36866, offset 0, flags [none], proto UDP (17), length 1405)
    10.0.0.101.5062 > 10.0.0.201.5060: SIP, length: 1377
    "INVITE sip:[email protected] SIP/2.0"

22:29:02.541085 IP (tos 0x60, ttl 64, id 22099, offset 0, flags [none], proto UDP (17), length 538)
    10.0.0.201.5060 > 10.0.0.101.5062: SIP, length: 510
    "SIP/2.0 100 Trying"
    
22:29:02.546553 IP (tos 0x60, ttl 64, id 22102, offset 0, flags [none], proto UDP (17), length 554)
    10.0.0.201.5060 > 10.0.0.101.5062: SIP, length: 526
    "SIP/2.0 180 Ringing" # but this is too early!
    
22:29:02.770970 IP (tos 0x60, ttl 64, id 22111, offset 0, flags [none], proto UDP (17), length 526)
    10.0.0.201.5060 > 10.0.0.101.5062: SIP, length: 498
    "SIP/2.0 503 Service Unavailable"

Solution 1:

Asterisk is PBX and designed in a way it can't control channel-level answer. There are no hacks for this in chan_sip too. Just because chan_sip is designed in a way it is almost impossible.

You can use kamailio/opensips(proxy type), which give 100% control over sip packets.

You can try play with following options(and thats all).

;prematuremedia=no              ; Some ISDN links send empty media frames before
                                ; the call is in ringing or progress state. The SIP
                                ; channel will then send 183 indicating early media
                                ; which will be empty - thus users get no ring signal.
                                ; Setting this to "yes" will stop any media before we have
                                ; call progress (meaning the SIP channel will not send 183 Session
                                ; Progress for early media). Default is "yes". Also make sure that
                                ; the SIP peer is configured with progressinband=never.
                                ;
                                ; In order for "noanswer" applications to work, you need to run
                                ; the progress() application in the priority before the app.

;progressinband=no              ; If we should generate in-band ringing. Always
                                ; use 'never' to never use in-band signalling, even in cases
                                ; where some buggy devices might not render it
                                ; Valid values: yes, no, never Default: no

Another option is just to rewrite chan_sip and hardcode your required behavour.