[Serusers] Troubles matching 487's to subsequent ACKs

Maxim Sobolev sobomax at portaone.com
Sun Jul 20 11:02:17 CEST 2003


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
> 
> 
> 




More information about the sr-users mailing list