[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