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:117@10.0.0.201 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"
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.