SIP/2.0 100 -to- SIP/2.0 200 OK - Answered Prematurely


Asterisk version

After placing a call my SIP provider does not send a SIP/2.0 180 -or- SIP/2.0 183 packet. This is causing Asterisk to consider the call answered before the dialed party actually answers, which is causing my dial plan to move down the priority list prematurely.

I understand the SIP provider is configured incorrectly by not sending a 180 and 183.
Are there any workarounds for this?

Here’s an example of the SIP trace where this happens:

<--- SIP read from --->
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP;branch=z9hG4bK4163f136;rport=5060;
From: "V0419214134000000024" <sip:xxxxxxx@>;tag=as4e639136
To: <;cpd=on>
Call-ID: 6c34aedd6444f59b3224e79a5fd7a18e@
CSeq: 102 INVITE
Content-Length: 0

--- (8 headers 0 lines) ---

<--- SIP read from --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP;;branch=z9hG4bK4163f136;rport=5060
Record-Route: <;lr=on;nat=yes;did=12a.1d6fe1a7>
From: "V0419214134000000024" <sip:xxxxxxxxxxxxx@>;tag=as4e639136
To: <;cpd=on>;tag=as42dc8b6a
Call-ID: 6c34aedd6444f59b3224e79a5fd7a18e@
CSeq: 102 INVITE
Server: Asterisk PBX
Supported: replaces, timer
Contact: <>
Content-Type: application/sdp
Content-Length: 278

Here’s my dial plan with flags:

exten => _91.,1,Dial(SIP/${EXTEN:1}@sip-provider,,oghr)
exten => _91.,2,Hangup

It is not a protocol violation to go directly to 200 OK, although it does look as though your provider is sending Answer instead of Progress. I suspect you are using a service intended only to be used directly with IP phones, not one designed for PABXes.

It is possible to run subroutines on the called party on answer, and I guess that you could use silence detection, etc., applications, to sense when the provider should have sent 200.

You can also split the call to run dialplan on both channels, and then use Bridge to put them back together.

Can you provide some examples of this please? I’ve been attempting to use Background Detect and Wait for silence with no luck.

No. All the dowstream SIP services I use are well behaved, so I have never had to research this in detail.