[asterisk-bugs] [JIRA] (ASTERISK-24915) Missing Contact: header in 200 OK
Etienne Allovon (JIRA)
noreply at issues.asterisk.org
Thu Mar 26 08:25:35 CDT 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-24915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Etienne Allovon updated ASTERISK-24915:
---------------------------------------
Description:
*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 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:
*Summary*
In some case 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 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
> 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
>
> *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 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