[Serusers] Troubles matching 487's to subsequent ACKs

Maxim Sobolev sobomax at portaone.com
Fri Jul 18 03:23:29 CEST 2003 

I checked the RFCs - ATA is clearly violates 3261 in this area*), but 
older 2543 doesn't contain any restriction on extra parameters that the 
UA places into ACK's Via. I will open a Cisco TAC case on this, but 
doubt that Cisco may resort to responding that ATA is only supposed to 
be RFC2543-compliant. Actually this brings another broader question - is 
SER expected to work only with RFC3261-compliant UAs, or this compliance 
is recommended but not strictly required? In the latter case ACK 
matching rules need to be relaxed a bit.

-Maxim

17.1.1.3 Construction of the ACK Request

    This section specifies the construction of ACK requests sent within
    the client transaction.  A UAC core that generates an ACK for 2xx
    MUST instead follow the rules described in Section 13.

    The ACK request constructed by the client transaction MUST contain
    values for the Call-ID, From, and Request-URI that are equal to the
    values of those header fields in the request passed to the transport
    by the client transaction (call this the "original request").  The To
    header field in the ACK MUST equal the To header field in the
    response being acknowledged, and therefore will usually differ from
    the To header field in the original request by the addition of the
    tag parameter.  The ACK MUST contain a single Via header field, and
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    this MUST be equal to the top Via header field of the original
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    request.  The CSeq header field in the ACK MUST contain the same
    ^^^^^^^^
    value for the sequence number as was present in the original request,
    but the method parameter MUST be equal to "ACK".


Maxim Sobolev wrote:

> Hi,
> 
> We have recently switched to 0.8.11 for our production server and
> I have noticed that ser no longer can match 487 Request cancelled
> reply to subsequent ACK, at least in the cases when ATA186 with
> latest firmware 2.16 is used as the originating UA. I wonder
> who is responsible for this: ATA or SER. The only strange thing
> that I see in the log is that ATA includes the following extra
> parameters into the first Via hf: rport=5060;received=195.234.212.178.
> 
> ATA->SER
> 
> INVITE sip:380445732729 at 64.180.102.72;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.0.253:5060
> From: <sip:380442466396 at 64.180.102.72;user=phone>;tag=4197094684
> To: <sip:380445732729 at 64.180.102.72;user=phone>
> Call-ID: 2777157492 at 192.168.0.253
> CSeq: 2 INVITE
> Contact: <sip:380442466396 at 192.168.0.253:5060;user=phone;transport=udp>
> User-Agent: Cisco ATA 186  v2.16 ata18x (030509a)
> Authorization: Digest username="380442466396",realm="64.180.102.72",nonce="3f168
> ef30be264b823354f5b14bef51f8c3636de",uri="sip:380445732729 at 64.180.102.72",respon
> se="d5a544d0eb3103e9f67b4e2af839054d"
> Expires: 300
> Content-Length: 257
> Content-Type: application/sdp
> o=380442466396 40288 40288 IN IP4 192.168.0.253
> s=ATA186 Call
> c=IN IP4 192.168.0.253
> t=0 0
> m=audio 13000 RTP/AVP 4 8 0 101
> a=rtpmap:4 G723/8000/1
> a=rtpmap:8 PCMA/8000/1
> a=rtpmap:0 PCMU/8000/1
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> 
> SER->ATA
> 
> SIP/2.0 100 trying -- your call is important to us
> Via: SIP/2.0/UDP 192.168.0.253:5060;rport=5060;received=195.234.212.178
> From: <sip:380442466396 at 64.180.102.72;user=phone>;tag=4197094684
> To: <sip:380445732729 at 64.180.102.72;user=phone>
> Call-ID: 2777157492 at 192.168.0.253
> CSeq: 2 INVITE
> Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
> Content-Length: 0
> 
> SER->ATA
> 
> SIP/2.0 183 Session Progress
> Via: SIP/2.0/UDP 192.168.0.253:5060;rport=5060;received=195.234.212.178
> To: <sip:380445732729 at 64.180.102.72;user=phone>;tag=d429e01d
> From: <sip:380442466396 at 64.180.102.72;user=phone>;tag=4197094684
> Call-ID: 2777157492 at 192.168.0.253
> CSeq: 2 INVITE
> Record-Route: <sip:380445732729 at 64.180.102.72;lr>
> Content-Type: application/sdp
> Content-Length: 283
> o=CiscoSystemsSIP-GW-UserAgent 503 692 IN IP4 212.119.160.61
> s=SIP Call
> c=IN IP4 212.119.160.61
> t=0 0
> m=audio 17182 RTP/AVP 4 19 101
> c=IN IP4 212.119.160.61
> a=rtpmap:4 G723/8000
> a=rtpmap:19 CN/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:4 annexa=no
> a=fmtp:101 0-15
> 
> ATA->SER
> 
> CANCEL sip:380445732729 at 64.180.102.72;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.0.253:5060
> From: <sip:380442466396 at 64.180.102.72;user=phone>;tag=4197094684
> To: <sip:380445732729 at 64.180.102.72;user=phone>
> Call-ID: 2777157492 at 192.168.0.253
> CSeq: 2 CANCEL
> User-Agent: Cisco ATA 186  v2.16 ata18x (030509a)
> Authorization: Digest username="380442466396",realm="64.180.102.72",nonce="3f168
> ef30be264b823354f5b14bef51f8c3636de",uri="sip:380445732729 at 64.180.102.72",respon
> se="2953586e366141c5b8062cdfe7678357"
> Content-Length: 0
> 
> SER->ATA
> 
> SIP/2.0 200 cancelling
> Via: SIP/2.0/UDP 192.168.0.253:5060;rport=5060;received=195.234.212.178
> From: <sip:380442466396 at 64.180.102.72;user=phone>;tag=4197094684
> To: <sip:380445732729 at 64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
> 5d5c-7fd1
> Call-ID: 2777157492 at 192.168.0.253
> CSeq: 2 CANCEL
> Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
> Content-Length: 0
> 
> 
> SER->ATA
> 
> SIP/2.0 487 Request cancelled
> Via: SIP/2.0/UDP 192.168.0.253:5060;rport=5060;received=195.234.212.178
> From: <sip:380442466396 at 64.180.102.72;user=phone>;tag=4197094684
> To: <sip:380445732729 at 64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
> 5d5c-7fd1
> Call-ID: 2777157492 at 192.168.0.253
> CSeq: 2 INVITE
> Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
> Content-Length: 0
> 
> ATA->SER
> 
> ACK sip:380445732729 at 64.180.102.72;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.0.253:5060;rport=5060;received=195.234.212.178
> From: <sip:380442466396 at 64.180.102.72;user=phone>;tag=4197094684
> To: <sip:380445732729 at 64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
> 5d5c-7fd1
> Call-ID: 2777157492 at 192.168.0.253
> CSeq: 2 ACK
> User-Agent: Cisco ATA 186  v2.16 ata18x (030509a)
> Content-Length: 0
> 
> SER->ATA
> 
> SIP/2.0 487 Request cancelled
> Via: SIP/2.0/UDP 192.168.0.253:5060;rport=5060;received=195.234.212.178
> From: <sip:380442466396 at 64.180.102.72;user=phone>;tag=4197094684
> To: <sip:380445732729 at 64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
> 5d5c-7fd1
> Call-ID: 2777157492 at 192.168.0.253
> CSeq: 2 INVITE
> Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
> Content-Length: 0
> 
> ATA->SER
> 
> ACK sip:380445732729 at 64.180.102.72;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.0.253:5060;rport=5060;received=195.234.212.178
> From: <sip:380442466396 at 64.180.102.72;user=phone>;tag=4197094684
> To: <sip:380445732729 at 64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
> 5d5c-7fd1
> Call-ID: 2777157492 at 192.168.0.253
> CSeq: 2 ACK
> User-Agent: Cisco ATA 186  v2.16 ata18x (030509a)
> Content-Length: 0
> 
> An so on (487->ACK->487->ACK until timeout hits).
> 
> -Maxim
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> 
> .
>

More information about the sr-users mailing list