[asterisk-bugs] [JIRA] (ASTERISK-24915) [patch]Missing Contact: header in 200 OK

[Joshua Colp (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231876#comment-231876 ] 

Joshua Colp commented on ASTERISK-24915:
----------------------------------------

All contributions to Asterisk go through code review using Gerrit. Since the individual who created the attached patch did not do so it falls to someone else to do so and take it through the process, that has not yet happened.

> [patch]Missing Contact: header in 200 OK
> ----------------------------------------
>
>                 Key: ASTERISK-24915
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24915
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.32.2, 11.16.0
>            Reporter: Etienne Allovon
>         Attachments: AST-24915.diff, ASTERISK-24915-asterisk-extensions.conf, ASTERISK-24915-asterisk-full.log, ASTERISK-24915-asterisk-sip.conf, ASTERISK-24915.pcapng, REGISTER_INVITE_client.csv, REGISTER_INVITE_client.xml
>
>
> *Summary*
> In some cases asterisk answers a call (SIP 200 OK) without the {{Contact:}} header.
> It results, for the receiving peer, to terminate the call (SIP BYE) because he can't answer.
> For example, if the receiving peer is an asterisk, you get the following WARNING in the CLI :
> {code}
> WARNING[32089] chan_sip.c: Invalid contact uri  (missing sip: or sips:), attempting to use anyway
> {code}
> More precisely this happens when asterisk receives a SIP message with a bad CSeq (for example with CSeq-1). Then the next 200 OK doesn't contain the Contact: header.
> *When does it happen in real life ?*
> In real life I saw it with two asterisk interconnected with a SIP trunk via a WAN.
> When there is some asymetric latency it results in retransmissions.
> {code}
> < INVITE            (CSeq 1)
> > 401 Unauthorized  (CSeq 1)
> > 401 Unauthorized  (CSeq 1) .... retransmission because ACK is not received on time
> < ACK               (CSeq 1) .... ACK of the first 401 Unauthorized
> < INVITE            (CSeq 2)
> > 100 Trying        (CSeq 2)  
> > 180 Ringing       (CSeq 2)
> < ACK               (Cseq *1*) .. ACK of the retransmitted 401 Unauthorized
> > 200 OK            (Cseq 2) .... /!\ which does not contain the Contact: header
> {code}
> *How to reproduce*
> Below is a SIP exchange forged with SIPp which reproduce the problem :
> {code}
> < INVITE            (CSeq 1)
> > 401 Unauthorized  (CSeq 1)
> < ACK               (CSeq 1)
> < INVITE            (CSeq 2)
> > 100 Trying        (CSeq 2) ..... contains Contact: header
> > 180 Ringing       (CSeq 2) ..... contains Contact: header
> < ACK               (Cseq *1*)
> > 200 OK            (Cseq 2) ..... /!\ does not contain Contact: header
> {code}
> The bug appears at step #7.
> Asterisk seems to handle the spurious ACK correctly since you find the following DEBUG message :
> {code}
> DEBUG[26739] chan_sip.c: **** Received ACK (6) - Command in SIP ACK
> DEBUG[26739] chan_sip.c: Ignoring too old SIP packet packet 1 (expecting >= 2)
> DEBUG[26739] chan_sip.c: SIP message could not be handled, bad request: 261113e445fb3f8777068f5513a8d61f at 10.14.12.1:5060
> {code}
> Here's the SIPp command to launch the scenario :
> {code}
> /usr/src/sipp-3.3/sipp 192.168.18.55 -sf REGISTER_INVITE_client.xml -inf REGISTER_INVITE_client.csv -i 192.168.18.11 -m 1 -l 1 -r 1
> {code}
> You need to :
> * replace 192.168.18.65 asterisk IP,
> * replace 192.168.18.11 with SIPp client IP
> * get the REGISTER_INVITE_client.xml file,
> * get the REGISTER_INVITE_client.csv file and change the authentication information
> *References*
> SIPp scenarios based on examples found here : http://tomeko.net/other/sipp/sipp_cheatsheet.php?lang



--
This message was sent by Atlassian JIRA
(v6.2#6252)