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

[Etienne Allovon (JIRA)]

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

Etienne Allovon updated ASTERISK-24913:
---------------------------------------

    Description: 
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

  was:
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.




****** ADDITIONAL 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.


> 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)