[asterisk-bugs] [Asterisk 0012706]: Violation of RFC 3261
noreply at bugs.digium.com
noreply at bugs.digium.com
Thu May 22 19:46:19 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=12706
======================================================================
Reported By: falves11
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 12706
Category: Channels/chan_sip/Interoperability
Reproducibility: always
Severity: major
Priority: normal
Status: new
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 117297
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 05-21-2008 17:26 CDT
Last Modified: 05-22-2008 19:46 CDT
======================================================================
Summary: Violation of RFC 3261
Description:
I have received this from our Client's SBC supplier: -
The INVITE from the asterisk has a "Supported: replaces, timer" header in
it. The 200 OK comes back from the NBS with "Require: timer", and the
ACK
from the asterisk has "Require: timer". This is a violation of RFC
3261
section 8.2.2.3:
An ACK request for a 2xx response MUST contain only those Require
and
Proxy-Require values that were present in the initial request.
I have highlighted the area in question at the bottom of your ACK below.
Please see if you can modify the ACK and make a test call.
Looking back at your calls last week before you upgraded your asterisk
your invites did not contain this field at all - Supported: replaces,
timer.
Your Cisco is in spec and does not contain the request:timer in the ACK
Frame 563 (548 bytes on wire, 548 bytes captured)
Arrival Time: May 21, 2008 20:28:22.927514000
[Time delta from previous packet: 0.057815000 seconds]
[Time since reference or first frame: 3.950214000 seconds]
Frame Number: 563
Packet Length: 548 bytes
Capture Length: 548 bytes
[Frame is marked: True]
[Protocols in frame: eth:ip:udp:sip]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Cisco_7e:88:20 (00:d0:97:7e:88:20), Dst:
AcmePack_01:c9:84 (00:08:25:01:c9:84)
Destination: AcmePack_01:c9:84 (00:08:25:01:c9:84)
Address: AcmePack_01:c9:84 (00:08:25:01:c9:84)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: Cisco_7e:88:20 (00:d0:97:7e:88:20)
Address: Cisco_7e:88:20 (00:d0:97:7e:88:20)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: 208.51.238.10 (208.51.238.10), Dst: 208.49.73.12
(208.49.73.12)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 534
Identification: 0x2b7b (11131)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 61
Protocol: UDP (0x11)
Header checksum: 0x78e0 [correct]
[Good: True]
[Bad : False]
Source: 208.51.238.10 (208.51.238.10)
Destination: 208.49.73.12 (208.49.73.12)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Source port: 5060 (5060)
Destination port: 5060 (5060)
Length: 514
Checksum: 0xe9d4 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Session Initiation Protocol
Request-Line: ACK sip:15852551531 at 208.49.73.12:5060;transport=udp
SIP/2.0
Method: ACK
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 208.51.238.10:5060;branch=z9hG4bK68bb430b;rport
Transport: UDP
Sent-by Address: 208.51.238.10
Sent-by port: 5060
Branch: z9hG4bK68bb430b
RPort: rport
Max-Forwards: 70
From: "7864335989" <sip:7864335989 at Xynergia>;tag=as009bc7da
SIP Display info: "7864335989"
SIP from address: sip:7864335989 at Xynergia
SIP tag: as009bc7da
To: <sip:15852551531 at 208.49.73.12>;tag=SDqmi8899-gK06abe5a2
SIP to address: sip:15852551531 at 208.49.73.12
SIP tag: SDqmi8899-gK06abe5a2
Contact: <sip:7864335989 at 208.51.238.10>
Contact Binding: <sip:7864335989 at 208.51.238.10>
URI: <sip:7864335989 at 208.51.238.10>
SIP contact address: sip:7864335989 at 208.51.238.10
Call-ID: 3f3db0f04e67ca706c41f50058aedbf8 at Xynergia
CSeq: 102 ACK
Sequence Number: 102
Method: ACK
User-Agent: Asterisk PBX SVN-trunk-r117401
Require: timer
Session-Expires: 64800;refresher=uac
Min-SE: 90
Content-Length: 0
======================================================================
----------------------------------------------------------------------
rjain - 05-22-08 19:46
----------------------------------------------------------------------
I just uploaded a fix for this issue (chan_sip.c.diff). While testing the
trunk, I stumbled upon another issue, which is also resolved in this patch.
That issue was introduced when someone converted sprintf to snprintf in the
transmit_invite() function.
Issue History
Date Modified Username Field Change
======================================================================
05-22-08 19:46 rjain Note Added: 0087230
======================================================================
More information about the asterisk-bugs
mailing list