[asterisk-bugs] [JIRA] (ASTERISK-24913) CLONE - missing Contact header in 200 OK to INVITE

[Joshua Colp (JIRA)]

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

Joshua Colp closed ASTERISK-24913.
----------------------------------

    Resolution: Suspended

Please don't clone issues like this. If you are encountering the same issue on a supported version of Asterisk create a new issue with details.

> CLONE - missing Contact header in 200 OK to INVITE
> --------------------------------------------------
>
>                 Key: ASTERISK-24913
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24913
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Core/General
>    Affects Versions: 11.16.0
>            Reporter: Etienne Allovon
>            Assignee: Matt Jordan
>         Attachments: full, missing_contact.pcap
>
>
> Several users of our softphone report a bug, that Asterisk 1.6.x does not always send Contact: header in response to our INVITE.
> The Contact arrives in 100 Trying, but not in 183 Session Progress nor 200 OK.
> We suspect is has something to do with 401 Unauthorized response to the initial INVITE.
> If there's no lag and the session goes like INVITE, 401 Unauthorized, ACK, INVITE, 100 Trying, 183 Session Progress, 200 OK, everything is fine.
> However we sometimes introduce a delay during the early stage and the session starts like this:
> > INVITE (CSeq 1)
> < 401 Unauthorized (CSeq 1) 
> > ACK (CSeq 1)
> > INVITE (CSeq 2)
> < 401 Unauthorized (CSeq 1)
> > ACK (CSeq 1)
> < 100 Trying (CSeq 2)   ..... contains Contact:
> < 183 Session Progress  .. no Contact:
> < 200 OK .. no Contact:
> we then report error as our SIP stack is unable to continue.
> *Additionnal information*
> In production it mainly occurs when you have asymetric latency between two SIP endpoints (for example two asterisk).
> It occurs with version 1.8.x and 11.x of asterisk.
> *How to reproduce*
> Here's a forged SIP exchange with SIPp represented with asterisk point of view. It simulates the call flow described above.
>     < 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) .......... no Contact: header
> The bug appears at step #7.
> Asterisk seems to handle the spurious ACK correctly since you find the following DEBUG message :
> 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
> Here's the SIPp command to launch the scenario :
> /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
> You need to :
>     use the IP of your asterisk server instead of 192.168.18.65,
>     get the REGISTER_INVITE_client.xml file,
>     get the REGISTER_INVITE_client.csv file and change the authentication information
>     use the IP of the SIPp client instead of 192.168.18.11



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