[asterisk-bugs] [Asterisk 0012706]: Violation of RFC 3261

Thu Jun 5 06:35:01 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:                     ready for testing
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:              06-05-2008 06:35 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
====================================================================== 

---------------------------------------------------------------------- 
 falves11 - 06-05-08 06:35  
---------------------------------------------------------------------- 
any idea about when it is going to be merged? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-05-08 06:35  falves11       Note Added: 0087838                          
======================================================================