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

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-24915:
------------------------------------

    Assignee: Etienne Allovon
      Status: Waiting for Feedback  (was: Triage)

Thanks for the detailed and thorough report!

In case we run into issues in reproduction, would you also be able to attach a pcap of the issue playing out, along with the Asterisk logs (with 'DEBUG' logger channel on and turned up to 5).

After this, remember to hit Send Back or Enter Feedback so we'll see the issue. Thanks again!


> 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
>            Assignee: Etienne Allovon
>         Attachments: 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)