[Home]

Summary:ASTERISK-12067: Violation of RFC 3261
Reporter:Private Name (falves11)Labels:
Date Opened:2008-05-21 17:26:42Date Closed:2008-06-10 09:04:39
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.c.diff
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@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@Xynergia>;tag=as009bc7da
           SIP Display info: "7864335989"
           SIP from address: sip:7864335989@Xynergia
           SIP tag: as009bc7da
       To: <sip:15852551531@208.49.73.12>;tag=SDqmi8899-gK06abe5a2
           SIP to address: sip:15852551531@208.49.73.12
           SIP tag: SDqmi8899-gK06abe5a2
       Contact: <sip:7864335989@208.51.238.10>
           Contact Binding: <sip:7864335989@208.51.238.10>
               URI: <sip:7864335989@208.51.238.10>
                   SIP contact address: sip:7864335989@208.51.238.10
       Call-ID: 3f3db0f04e67ca706c41f50058aedbf8@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

****** ADDITIONAL INFORMATION ******

This is major issue since the calls do not go through to our main provider. We recently upgraded to Trunk from 1.2, a version that does not seem to have any such issues, but has plenty of others. We want to stay in Trunk, for the ODBC usage is a lot smarter than 1.4.
Comments:By: Brandon Kruse (bkruse) 2008-05-21 21:54:40

If trunk fixes the problem, then great. (I would not recommend directly using in production, however). No bug fixes will happen for 1.2

-bk
By: Private Name (falves11) 2008-05-21 21:58:38

I am sorry I did not express myself correctly. We still have the issue. The issue happens in Trunk, not in 1.2. So we need to fix Trunk. I am bound to use Trink because of the ODBC enhancements and also because of the directrtp feature. Can somebody please look into this? The Session Border Controller that complains is a Sonus, and all major carriers use it. We need to be able to send calls to a Sonus.
By: Raj Jain (rjain) 2008-05-22 18:42:21

Yes, it does seem that we're not compliant with that normative text in RFC 3261. You can workaround this by not requesting session-timers for the time being. Set session-timers=accept in your sip.conf for this particular peer or globally whatever suits you.

I'm actually the one who is guilty of this bug. I'll post a patch soon.
By: Raj Jain (rjain) 2008-05-22 19:46:18

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.
By: Private Name (falves11) 2008-05-22 19:48:27

I will test it in production for a dew days and let you know. But I cannot really tell until the same carrier, Global Crossing, schedules a test again and it will be next week.


By: Raj Jain (rjain) 2008-05-30 09:57:09

I've tested this patch with a few end-points and things are working as expected. We've dropped the Require: timer header from the ACK request. Also, we've fixed the Min-SE header population in the INVITE request.

I think we should be able to check this in the trunk.
By: Private Name (falves11) 2008-06-05 06:35:00

any idea about when it is going to be merged?
By: Digium Subversion (svnbot) 2008-06-10 09:04:31

Repository: asterisk
Revision: 121503

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r121503 | file | 2008-06-10 09:04:30 -0500 (Tue, 10 Jun 2008) | 7 lines

Fix issue where session timer headers were present when they should not have been.
(closes issue ASTERISK-12067)
Reported by: falves11
Patches:
     chan_sip.c.diff uploaded by rjain (license 226)
Tested by: falves11

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=121503