| Summary: | ASTERISK-22558: Asterisk should not send re-invite and update during P-Asserted in call | ||
| Reporter: | David Brillert (aragon) | Labels: | |
| Date Opened: | 2013-09-19 11:22:20 | Date Closed: | 2013-11-15 08:29:55.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/CallerID |
| Versions: | 11.5.1 | Frequency of Occurrence | Frequent |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) call_ID_CS2.pcapng ( 1) sip.conf.txt | |
| Description: | An incoming call to Asterisk IVR and user dials digits to dial extension.
The trunk has PAI yes the extension has PAI yes. Asterisk sends the PAI update and re-invite in same call then the SBC responds with a 500 internal server error and Asterisk never sends an ACK. pcap attached. There is no RTP and the dial plan continues to execute. | ||
| Comments: | By: David Brillert (aragon) 2013-09-19 11:24:20.302-0500 The update should be enough, not sure why the re-invite is necessary... By: Rusty Newton (rnewton) 2013-10-03 20:11:40.884-0500 David thanks for the report, can you attach your sanitized complete SIP configuration? By: David Brillert (aragon) 2013-10-21 10:01:53.968-0500 Here is sip.conf from general and tenant/default contexts including relevant scrubbed extension and trunk. By: Rusty Newton (rnewton) 2013-10-25 18:27:10.788-0500 Okay, hmm. We'll probably need an Asterisk log of the same call in the pcap, showing VERBOSE,DEBUG (both at 5 or above) and "sip set debug on". I should have asked for that earlier on, sorry about that! By: Rusty Newton (rnewton) 2013-11-14 09:57:35.294-0600 David we'll need an Asterisk log as described for the accompanying pcap to move forward. By: David Brillert (aragon) 2013-11-15 08:29:05.860-0600 We fixed the problem by changing PAI to RPID and I am not going to ask the customer to change back and break the network. PAI Asterisk to Asterisk does not give us any trouble but Asterisk PAI to Freeswitch was giving us trouble. By: David Brillert (aragon) 2013-11-15 08:29:55.765-0600 I'm closing this out until I can see an opportunity to reproduce without causing customer downtime. By: Steve Davies (one47) 2014-05-15 09:33:31.493-0500 I have also seen this issue, in 1.8.27.0, and will endeavour to provide a repeatable sequence. By: Steve Davies (one47) 2014-05-16 11:55:15.099-0500 No solution yet, but definitely repeatable. Worse than that, I have 2 cases, one which causes it and one which does not, but I still cannot see what is causing the differing behaviour! Same for both cases: - Inbound SIP call - Answer() + Playback(...) - Caller DTMF press causes Goto - Set CONNECTEDLINE(num) ... CoLP Re-INVITE sent - Set CONNECTEDLINE(name) ... CoLP UPDATE sent because we are already in-dialog Continues with working case: - Dial() a SIP device to connect caller to. ... Onward INVITE sent to new channel ... CoLP UPDATE 2 sent because we are already in-dialog ... 100 Trying received for INVITE ... 500 Error received for UPDATE ... 500 Error received for UPDATE 2 ... OK/ACK proceeds for Re-INVITE, call is okay. or with not working case: - Start a Playback(...) ... 100 Trying received for INVITE ... 500 Error received for UPDATE ... OK received for Re-INVITE ... Asterisk never sends ACK, call fails It is possible to work around the differences and cause it to work reliably by either using the 'i' parameter when setting CONNECTEDLINE, or by setting 'disallowed_methods=UPDATE' in sip.conf | ||