[Serusers] Troubles matching 487's to subsequent ACKs
Jiri Kuthan
jiri at iptel.org
Sun Jul 20 22:13:21 CEST 2003
What seems really necessary to me is Cisco removing dependency on an RFC which
was obsoleted longer than one year ago, and in particular on a feature (transaction
key calculation) which was completely broken in 2543 and repaired in 3261 (z9hG4bK).
I'm not opposed against a SER option for relaxed transaction matching, but I'm
currently too busy to create a workaround for this cisco bug. Feel free to supply
a patch against the development SER version.
-Jiri
At 11:02 AM 7/20/2003, Maxim Sobolev wrote:
>We had opened Cisco TAC case on this, but Cisco replied that ATA 3261 is only RFC2543-compliant and hence they will not fix the problem now. Therefore, IMO it is really necessary to provide some command line switch to relax Via matching rules.
>
>-Maxim
>
>Maxim Sobolev wrote:
>
>>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
>>>
>>>
>>>.
>>
>>_______________________________________________
>>Serusers mailing list
>>serusers at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serusers
>>
>
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
More information about the sr-users
mailing list