|Summary:||ASTERISK-10840: asterisk modifying the in-dialogue route set which is a violation of RFC3261|
|Reporter:||Rob Dyck (robertjdyck)||Labels:|
|Date Opened:||2007-11-20 14:07:35.000-0600||Date Closed:||2007-11-28 05:29:17.000-0600|
|Description:||The severity is marked as major because it may be a security threat.|
Although the problem is always reproducible I have not confirmed that it is an asterisk bug. I am not actually an asterisk user. My service provider uses asterisk for PSTN gateways. The service provider has not been forthcoming with version and configuration information nor have them offered to test with me. Perhaps someone with influence or insider knowledge could determine the asterisk version used by voxalot/sipbroker.
The suspected bug:
When the SIP UA calls through the PSTN gateway and the call is answered, the gateway does a re-INVITE to optimize the media path. The UA which is now acting as an UAS sends 200 OK. The expected ACK from the gateway never arrives and the 200 OK is retransmitted until the UAS times out and sends BYE. The critical clue is that if the UAS sending the 200 OK includes a Record-Route list, the call proceeds normally. If the UAS does not include the RR list when get the situation described above. This leads me to suspect that gateway is creating an empty route set when it does not receive an RR list. The ACK can not find its way to the UAS.
RFC 3261 is clear that the route set must not be modified after the dialogue is established. It states that an UAS MAY send RR but that it must influence the established route set. By implication, the lack of RR should not influence it either.
See RFC 3261 12.2 Requests within a Dialog
Please note that calls from the gateway to the UA even with re-INVITE, proceed normally. Also when the UA sends BYE ( with an RR list ), the gateway's response arrives at the UA.
|Comments:||By: Olle Johansson (oej) 2007-11-21 02:30:48.000-0600|
Hmm. I've already seen this in a bug report. Isn't this a duplicate?
By: Rob Dyck (robertjdyck) 2007-11-24 15:51:09.000-0600
Yes it appears to be a duplicate. I did not pick it up on my initial search due to the different spellings of the word dialog(ue).
Any progress to report?
By: pkempgen (pkempgen) 2007-11-27 13:43:44.000-0600
Sounds like a duplicate of 11230.