[asterisk-dev] [svn-commits] mmichelson: branch 1.8 r368625 - /branches/1.8/channels/chan_sip.c

[Olle E. Johansson]

6 jun 2012 kl. 21:13 skrev SVN commits to the Digium repositories:

> Author: mmichelson
> Date: Wed Jun  6 14:13:45 2012
> New Revision: 368625
> 
> URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=368625
> Log:
> Fix a specific scenario where ACKs are not matched.
> 
> If a dialog-starting INVITE contains a to-tag, then Asterisk
> will respond with a 481. In this case, the resulting incoming
> ACK would not be matched, so Asterisk would continue retransmitting
> the 481 until the transaction times out.
> 
> There were two issues. Asterisk, upon creating a sip_pvt would generate
> a local tag. However, when the time came to transmit the 481, since there
> was a to-tag in the INVITE, Asterisk would place this original to-tag
> in the 481 response. When the ACK came in, Asterisk would attempt to
> match the to-tag in the ACK to the generated local tag. Unfortunately,
> Asterisk never actually transmitted a response with the generated local
> tag, so the to-tag in the ACK would not match.
> 
> The other problem was that when the 481 was sent, nothing was set
> on the sip_pvt to indicate what CSeq is expected in the ACK.
> 
> To fix the first problem, we zero out the to-tag seen in the incoming
> INVITE. This way, Asterisk, when time to send a response, will send
> its generated local tag instead.
Which means that the sender of the SIP request can't match your response to the request. The to-tag is an important part
of the dialog-matching and you can't change it like that.

Did you test this with a number of devices?

/O