Summary:ASTERISK-17405: [patch] ACK is ignored upon call-pickup with sendrpid=yes
Reporter:Jan Klepal (kenny)Labels:patch
Date Opened:2011-02-14 13:32:15.000-0600Date Closed:
Versions:1.8.2 13.18.4 Frequency of
is the original version of this clone:ASTERISK-19765 CLONE - ACK is ignored upon call-pickup with sendrpid=yes
Environment:Attachments:( 0) chan_sip.c.patch
( 1) debug.txt
( 2) graph.txt
Description:Asterisk seems to ignore (can't match) ACK for 200+SDP message after SIP UPDATE with RPID is sent to phone.

1 - A calls to B
2 - C dials *8 to pickup call ringing on B
3 - Asterisk sends 200+SDP to C (which is confirmed by ACK)
4 - Asterisk sends CANCEL to B (which is confirmed by 487 request terminated)
5 - Asterisk sends 200+SDP and UPDATE to A
6 - now the call is connected and RTP stream is OK in both directions
7 - A confirms UPDATE with 200 message and then confirms 200+SDP with ACK
8 - however Asterisk keep sending 200+SDP
9 - until SIP timer expires and Asterisk hangup channel without notifying A (it only sends BYE to C)

Asterisk hangup channel with messages:
Retransmission timeout reached on transmission callid@ip for seqno 102 (Critical Response) -- See doc/sip-retransmit.txt.
Hanging up call callid@ip - no reply to our critical packet (see doc/sip-retransmit.txt).

In case RPID feature is disabled (sendrpid=no) then ACK is matched properly.


In the attached dump ACK is received at 2011-02-14 20:01:44.070
Comments:By: Jan Klepal (kenny) 2011-08-17 06:16:45.412-0500

I did more investigation on the issue and found this behavior is caused by 200 response packet to UPDATE message. When the response is received pendinginvite is set to 0 in SIP dialog structure.

A calls B, C does pickup

Phone A <---> Asterisk
1 ---> INVITE CSeq 101
2 <--- 401 Unauthorized
3 ---> ACK CSeq 101
4 ---> INVITE Cseq 102
5 <--- 100 Trying
6 <--- 180 Ringing
--- callpickup made on phone C ---
7 <--- 200 CSeq 102 INVITE
8 <--- UPDATE CSeq 102
9 ---> 200 CSeq 102 UPDATE
10 ---> ACK CSeq 102

For some unknown reason phone ingore 7th packet and send response to 8th (UPDATE). This incorrectly confirms pending INVITE because icseq = ocseq = 102. Following ACK (10th packet) is ignored because pendinginvite is now 0. However Asterisk keeps resending 200 CSeq 102 INVITE because it is in sheduler and after timer timeouts call is droped.

I am not sure what is correct solution. Quick and probably dirty is to extend condition in __sip_ack function which sets pendinginvite to ingore UPDATE. Originaly I though that setting pendinginvite to zero should be done only for ACK packets because __sip_reliable_xmit function set pendinginvite only for INVITE metod but transmit_state_notify function set pendinginvite too and even there is some workaround for buggy clients which sends ACK on ringing. So I think there must be !resp && (seqno == p->pendinginvite) && sipmethod != SIP_UPDATE.

By: ibercom (ibercom) 2012-04-24 17:16:20.637-0500

What about this ?
If I originated calls, they hang up in 6 sec.
Is sendrpid (SIP UPDATE) a problem ?

The above patch doesn't work.

By: Jan Klepal (kenny) 2012-04-24 18:33:02.219-0500

This "patch" solves only one particular scenario. Later I discovered there are some more call scenarios which fails too (and it wasn't so simple to fix it by just modifying some conditions). Workaround is to use TCP as transport protocol for SIP. At least it solved all my problems with Cisco 79xx phones. Check ASTERISK-13145 for more info about Cisco phones integration.

By: Joe Searle (jsearle) 2015-07-17 05:09:17.401-0500

Any idea when this patch is going to be merged?

By: Joshua C. Colp (jcolp) 2015-07-17 05:19:56.784-0500

The process for patch submission is documented on the wiki[1]. Patches that are just attached to an issue generally take much longer as someone else has to take them through the code review process. If you'd like to speed it up you can submit it to gerrit.

[1] https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process