17 Jul
2003
17 Jul
'03
2:22 p.m.
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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Contact: <sip:380442466396@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@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=d429e01d
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Record-Route: <sip:380445732729@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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)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@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
Content-Length: 0
ATA->SER
ACK sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
Content-Length: 0
ATA->SER
ACK sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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
17 Jul
17 Jul
2:56 p.m.
Where can I get the firmware upgrade for ATA-186? I searched the CISCO
website but I found nothing.
Will you please help me?
Thanks,
Emery
----- Original Message -----
From: "Maxim Sobolev" <sobomax(a)portaone.com
To: <serusers(a)lists.iptel.org
Cc: <kapitan(a)portaone.com Sent: Thursday, July
17, 2003 15:22
Subject: [Serusers] Troubles matching 487's to subsequent ACKs
ef30be264b823354f5b14bef51f8c3636de",uri="sip:380445732729@64.180.102.72",re
spon
> 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@64.180.102.72;user=phone>;tag=4197094684
> To: <sip:380445732729@64.180.102.72;user=phone
> Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=d429e01d
> From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
> Call-ID: 2777157492(a)192.168.0.253
> CSeq: 2 INVITE
> Record-Route: <sip:380445732729@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@64.180.102.72;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.0.253:5060
> From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
> To: <sip:380445732729@64.180.102.72;user=phone
> Call-ID: 2777157492(a)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@64.180.102.72",re
spon
> 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@64.180.102.72;user=phone>;tag=4197094684
> To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
> 5d5c-7fd1
> Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
> To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
> 5d5c-7fd1
> Call-ID: 2777157492(a)192.168.0.253
> CSeq: 2 INVITE
> Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
> Content-Length: 0
> ATA->SER
> ACK
sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
> To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
> 5d5c-7fd1
> Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
> To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
> 5d5c-7fd1
> Call-ID: 2777157492(a)192.168.0.253
> CSeq: 2 INVITE
> Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
> Content-Length: 0
> ATA->SER
> ACK
sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
> To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
> 5d5c-7fd1
> Call-ID: 2777157492(a)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(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Contact: <sip:380442466396@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
18 Jul
18 Jul
12:20 a.m.
You can download it here:
http://www.cisco.com/pcgi-bin/tablebuild.pl/ata186.
Please note that you need a CCO account in order to download it.
-Maxim
Director General: NEFACOMP wrote:
Where can I get the firmware upgrade for ATA-186? I
searched the CISCO
website but I found nothing.
Will you please help me?
Thanks,
Emery
----- Original Message -----
From: "Maxim Sobolev" <sobomax(a)portaone.com>
To: <serusers(a)lists.iptel.org>
Cc: <kapitan(a)portaone.com>
Sent: Thursday, July 17, 2003 15:22
Subject: [Serusers] Troubles matching 487's to subsequent ACKs
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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Contact: <sip:380442466396@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@64.180.102.72",re
spon
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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=d429e01d
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Record-Route: <sip:380445732729@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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)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@64.180.102.72",re
spon
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@64.180.102.72;user=phone>;tag=4197094684
To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
Content-Length: 0
ATA->SER
ACK sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
Content-Length: 0
ATA->SER
ACK sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
.
3:23 a.m.
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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Contact: <sip:380442466396@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@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=d429e01d
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Record-Route: <sip:380445732729@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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)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@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
Content-Length: 0
ATA->SER
ACK sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
Content-Length: 0
ATA->SER
ACK sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
.
10:14 a.m.
New subject: [Serusers] Acc with Radius support failed.
I tried to load SER with Radius Account support. SER failed to start with the following
error message:
0(30753) ERROR: load_module: could not open module
</usr/local/lib/ser/modules/acc.so>: libradiusclient.so.0: cannot open shared object
file: No such file or directory
0(30753) parse error (42,13-47): failed to load module
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (54,32-33): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (58,33-34): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (59,31-32): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (62,31-32): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (64,42-43): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (65,41-42): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (66,58-59): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (67,29-30): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (68,35-36): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (69,37-38): Can't set module parameter
ERROR: bad config file (11 errors)
I cannot figure out what went wrong.
I installed my SER with the latest CVS. I also have radiusclient and freeradius installed
on the same machine.
Any idea?
3:09 p.m.
New subject: [Serusers] TDM Interface
Has anyone paired a TDM ( Channelized DS1 ) interface with the server to
allow gateway options to either PSTN or a PBX?
4:59 p.m.
New subject: [Serusers] TDM Interface
On (18.07.03 08:09), Nathan Littlepage wrote:
Has anyone paired a TDM ( Channelized DS1 ) interface
with the server to
allow gateway options to either PSTN or a PBX?
we have experience with Asterisk (http://www.asterisk.org). Works, and
adds a lot of other features as well (voicemail, conference brigde, you
name it). It's a soft PBX, but since it understands SIP, it can be
(mis)used as a gateway as well.
Definitely worth a look.
cheers
Alex Mayrhofer
nic.at
20 Jul
20 Jul
10:32 p.m.
New subject: [Serusers] Acc with Radius support failed.
you need to install radius library on your system. a possibility is you
installed the library but didn't tell your library loader about it
(see 'man ldconf').
-jiri
At 10:14 AM 7/18/2003, Younger Wang wrote:
I tried to load SER with Radius Account support. SER
failed to start with the following error message:
0(30753) ERROR: load_module: could not open module
</usr/local/lib/ser/modules/acc.so>: libradiusclient.so.0: cannot open shared object
file: No such file or directory
0(30753) parse error (42,13-47): failed to load module
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (54,32-33): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (58,33-34): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (59,31-32): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (62,31-32): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (64,42-43): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (65,41-42): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (66,58-59): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (67,29-30): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (68,35-36): Can't set module parameter
0(30753) set_mod_param_regex: No module matching acc found
| 0(30753) parse error (69,37-38): Can't set module parameter
ERROR: bad config file (11 errors)
I cannot figure out what went wrong.
I installed my SER with the latest CVS. I also have radiusclient and freeradius installed
on the same machine.
Any idea?
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
11:02 a.m.
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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Contact: <sip:380442466396@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@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=d429e01d
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Record-Route: <sip:380445732729@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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)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@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@64.180.102.72;user=phone>;tag=4197094684
To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
Content-Length: 0
ATA->SER
ACK sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
Content-Length: 0
ATA->SER
ACK sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
To:
<sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10:13 p.m.
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:
--
Jiri Kuthan http://iptel.org/~jiri/
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:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Contact: <sip:380442466396@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@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=d429e01d
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Record-Route: <sip:380445732729@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@64.180.102.72;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.253:5060
From: <sip:380442466396@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>
Call-ID: 2777157492(a)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@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
Content-Length: 0
ATA->SER
ACK sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)192.168.0.253
CSeq: 2 INVITE
Server: Sip EXpress router (0.8.11rc1 (i386/freebsd))
Content-Length: 0
ATA->SER
ACK sip:380445732729@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@64.180.102.72;user=phone>;tag=4197094684
To: <sip:380445732729@64.180.102.72;user=phone>;tag=7fe8c93a8cb9c58b2cde45b60b0e
5d5c-7fd1
Call-ID: 2777157492(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7761
days inactive
7764
days old
9 comments
6 participants
participants (6)
-
Alexander Mayrhofer -
Director General: NEFACOMP -
Jiri Kuthan -
Maxim Sobolev -
Nathan Littlepage -
Younger Wang