[asterisk-bugs] [JIRA] (ASTERISK-24913) CLONE - missing Contact header in 200 OK to INVITE
Etienne Allovon (JIRA)
noreply at issues.asterisk.org
Thu Mar 26 08:15:35 CDT 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-24913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Etienne Allovon updated ASTERISK-24913:
---------------------------------------
Description:
*Original 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:
{code}
> 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:
{code}
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*
Below is a SIP exchange forged with SIPp which reproduce the problem :
asterisk :
{{< 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}}
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 with you asterisk server IP,
* replace 192.168.18.11 with the 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
was:
*Original 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:
{code}
> 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:
{code}
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*
Below is a SIP exchange forged with SIPp which reproduce the problem :
asterisk :
{{ < 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}}
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 with you asterisk server IP,
* replace 192.168.18.11 with the 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
> 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
>
>
> *Original 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:
> {code}
> > 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:
> {code}
> 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*
> Below is a SIP exchange forged with SIPp which reproduce the problem :
> asterisk :
> {{< 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}}
> 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 with you asterisk server IP,
> * replace 192.168.18.11 with the 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)
More information about the asterisk-bugs
mailing list