7 Oct
2004
7 Oct
'04
10:04 p.m.
Hello guys,
I'm trying to understand what is happening with SER
and re-INVITEs (for T.38 fax).
I have the follwing scenario:
ATA -> Session Border(NAT) -> SER -> Cisco Gateway
The ATA connects to the Cisco gateway for a voice call
and when the gateway receives a fax tone is starts a
re-INVITE to try to negotiate T38 parameters. Then ATA
responds with 488 Not Supported Here and SER sends a
ACK back to the ATA before sending 488 to the gateway.
In this ACK it seems that SER is adding an extra route
header as the INVITE that was sent to the ATA had only
one route header. Why SER is adding two route headers?
I'm attaching ngrep logs to this mail (with some
further comments), where:
The IP 10.0.0.19 is the Proxy
The IP 10.0.0.67 is the gateway
The IP 10.0.0.18 is the Session Border (NAT)
Thanks in advance,
Chuck.
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
#
U 10.0.0.67:50549 -> 10.0.0.19:5060
INVITE sip:1234@10.0.0.19:5060;ftag=2482904200;lr SIP/2.0..Via: SIP/2.0/UDP
10.0.0.67:5060..Fro
m: <sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To:
<sip:55519@proxy.com;user=phone>;
tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12 GMT..Call-ID:
137792672@10.0.0.35..Route:
<sip:1234@10.0.0.18:5071>,
<sip:55519@10.0.0.18:5071;user=phone>..Supported: timer,100rel..Min-
SE: 1800..Cisco-Guid: 1053952464-397283801-2441193380-2221309272..User-Agent:
Cisco-SIPGateway/IOS-12.x..
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY,
INFO..CSeq: 101 INVITE..
Max-Forwards: 6..Remote-Party-ID:
<sip:55519@10.0.0.67>;party=calling;screen=no;privacy=off..Timestam
p: 1097163732..Contact: <sip:747%23555133280636@10.0.0.67:5060>..Expires:
180..Allow-Events: telephon
e-event..Content-Type: application/sdp..Content-Length:
402....v=0..o=CiscoSystemsSIP-GW-UserAgent 8783 11
68 IN IP4 10.0.0.67..s=SIP Call..c=IN IP4 10.0.0.67..t=0 0..m=image 18742 udptl
t38..c=IN IP4 20
0.175.202.67..a=T38FaxVersion:0..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0
..a=T38FaxTranscodingJBIG:0..a=T38FaxRateManagement:transferredTCF..a=T38FaxMaxBuffer:200..a=T38FaxMaxData
gram:72..a=T38FaxUdpEC:t38UDPRedundancy..
#
U 10.0.0.19:5060 -> 10.0.0.67:5060
SIP/2.0 100 Trying..Via: SIP/2.0/UDP 10.0.0.67:5060..From:
<sip:1234@proxy.com;user=
phone>;tag=48235ADC-1DB8..To:
<sip:55519@proxy.com;user=phone>;tag=2482904200..Call-ID: 13
7792672@10.0.0.35..CSeq: 101 INVITE..Server: Sip Router..Content-Length: 0....
#
====The INVITE sent to the ATA has only one route header======
U 10.0.0.19:5060 -> 10.0.0.18:5071
INVITE sip:1234@10.0.0.18:5071 SIP/2.0..Record-Route:
<sip:1234@10.0.0.19;ftag=48235ADC-1DB8;lr>
..Via: SIP/2.0/UDP 10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..Via: SIP/2.0/UDP
10.0.0.67:5060..Fr
om: <sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To:
<sip:55519@proxy.com;user=phone>;
tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12 GMT..Call-ID:
137792672@10.0.0.35..Route
: <sip:55519@10.0.0.18:5071;user=phone>..Supported: timer,100rel..Min-SE:
1800..Cisco-Guid: 10539524
64-397283801-2441193380-2221309272..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow:
INVITE, OPTIONS, BYE, CA
NCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO..CSeq: 101 INVITE..Max-Forwards:
5..Remote-Party-I
D: <sip:55519@10.0.0.67>;party=calling;screen=no;privacy=off..Timestamp:
1097163732..Contact: <sip:74
7%23555133280636@10.0.0.67:5060>..Expires: 180..Allow-Events:
telephone-event..Content-Type: applicat
ion/sdp..Content-Length: 402....v=0..o=CiscoSystemsSIP-GW-UserAgent 8783 1168 IN IP4
10.0.0.67..s=SIP
Call..c=IN IP4 10.0.0.67..t=0 0..m=image 18742 udptl t38..c=IN IP4
10.0.0.67..a=T38FaxVersion:0
..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0..a=T38FaxTranscodingJBIG:0..a=
T38FaxRateManagement:transferredTCF..a=T38FaxMaxBuffer:200..a=T38FaxMaxDatagram:72..a=T38FaxUdpEC:t38UDPRe
dundancy..
#
U 10.0.0.18:5071 -> 10.0.0.19:5060
SIP/2.0 488 Not Acceptable Here..Via: SIP/2.0/UDP
10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..Via: SIP/2
.0/UDP 10.0.0.67:5060..From:
<sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To: <
sip:55519@proxy.com;user=phone>;tag=2482904200..Call-ID: 137792672@10.0.0.35..CSeq:
101 IN
VITE..timestamp: 1097163732..server: Cisco ATA 186 v3.1.0 atasip (040211A)..warning:
Media type not avail
able..Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER..Content-Length:
0....
#
===========The ACK sent to ATA has two route headers, and the top route header is the same
as the R-Uri.
===========Is this correct?
U 10.0.0.19:5060 -> 10.0.0.18:5071
ACK sip:1234@10.0.0.18:5071 SIP/2.0..Via: SIP/2.0/UDP
10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..F
rom: <sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..Call-ID:
137792672@10.0.0.35..To:
<sip:55519@proxy.com;user=phone>;tag=2482904200..CSeq: 101 ACK..Route:
<sip:1234@10.0.0.18:5071>,
<sip:55519@10.0.0.18:5071;user=phone>..User-Agent: Sip Router..Content-Length
: 0....
#
U 10.0.0.19:5060 -> 10.0.0.67:5060
SIP/2.0 488 Not Acceptable Here..Via: SIP/2.0/UDP 10.0.0.67:5060..From:
<sip:1234@proxy.com;user=phone>;
tag=48235ADC-1DB8..To: <sip:55519@proxy.com;user=phone>;tag=2482904200.
.Call-ID: 137792672@10.0.0.35..CSeq: 101 INVITE..timestamp: 1097163732..server: Cisco
ATA 186 v3.1.0 atas
ip (040211A)..warning: Media type not available..Allow: ACK, BYE, CANCEL, INVITE,
NOTIFY, OPTIONS, REFER,
REGISTER..Content-Length: 0....
#
===========Supposing that this ACK was not absorved by the proxy, what would be the
behavior of loose_route()?
===========Wouldn't loose_route change the R-URI by the topmost router and then remove
it? If so, this ACK
===========would be equal to the one previously sent by ser but it would have only one
route header. Am I missing
===========something?
U 10.0.0.67:50549 -> 10.0.0.19:5060
ACK sip:1234@10.0.0.19:5060;ftag=2482904200;lr SIP/2.0..Via: SIP/2.0/UDP
10.0.0.67:5060..From:
<sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To:
<sip:55519@proxy.com;user=phone>;
tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12 GMT..Call-ID:
137792672@10.0.0.35..Route: <s
ip:1234@10.0.0.18:5071>, <sip:55519@10.0.0.18:5071;user=phone>..Max-Forwards:
6..Content-Length:
0..CSeq: 101 ACK....
#
8 Oct
8 Oct
11:03 a.m.
As described in RFC 3261, section 12.2 Requests within a Dialog :
"Requests within a dialog MAY contain Record-Route and Contact header
fields. However, these requests do not cause the dialog's route set to
be modified, although they may modify the remote target URI."
As the GW uses for the re-INVITE the route set learned via original
INVITE (there are 2 Route hdr in your re-INVITE), SER follows the same
principal and when generating the ACK, instead of using the RR from
re_INVITE reply, it uses also the Route set from RE-INVITE.
Anyhow, as you can see, the 488 reply doen't mirror at all the RR set,
since the .18 device knows that is a reply for a re-INVITE and the ROUTE
set is already established.
bogdan
Chuck Ramirez wrote:
Hello guys,
I'm trying to understand what is happening with SER
and re-INVITEs (for T.38 fax).
I have the follwing scenario:
ATA -> Session Border(NAT) -> SER -> Cisco Gateway
The ATA connects to the Cisco gateway for a voice call
and when the gateway receives a fax tone is starts a
re-INVITE to try to negotiate T38 parameters. Then ATA
responds with 488 Not Supported Here and SER sends a
ACK back to the ATA before sending 488 to the gateway.
In this ACK it seems that SER is adding an extra route
header as the INVITE that was sent to the ATA had only
one route header. Why SER is adding two route headers?
I'm attaching ngrep logs to this mail (with some
further comments), where:
The IP 10.0.0.19 is the Proxy
The IP 10.0.0.67 is the gateway
The IP 10.0.0.18 is the Session Border (NAT)
Thanks in advance,
Chuck.
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
------------------------------------------------------------------------
#
U 10.0.0.67:50549 -> 10.0.0.19:5060
INVITE sip:1234@10.0.0.19:5060;ftag=2482904200;lr SIP/2.0..Via: SIP/2.0/UDP
10.0.0.67:5060..Fro
m: <sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To:
<sip:55519@proxy.com;user=phone>;
tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12 GMT..Call-ID:
137792672@10.0.0.35..Route:
<sip:1234@10.0.0.18:5071>,
<sip:55519@10.0.0.18:5071;user=phone>..Supported: timer,100rel..Min-
SE: 1800..Cisco-Guid: 1053952464-397283801-2441193380-2221309272..User-Agent:
Cisco-SIPGateway/IOS-12.x..
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY,
INFO..CSeq: 101 INVITE..
Max-Forwards: 6..Remote-Party-ID:
<sip:55519@10.0.0.67>;party=calling;screen=no;privacy=off..Timestam
p: 1097163732..Contact: <sip:747%23555133280636@10.0.0.67:5060>..Expires:
180..Allow-Events: telephon
e-event..Content-Type: application/sdp..Content-Length:
402....v=0..o=CiscoSystemsSIP-GW-UserAgent 8783 11
68 IN IP4 10.0.0.67..s=SIP Call..c=IN IP4 10.0.0.67..t=0 0..m=image 18742 udptl
t38..c=IN IP4 20
0.175.202.67..a=T38FaxVersion:0..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0
..a=T38FaxTranscodingJBIG:0..a=T38FaxRateManagement:transferredTCF..a=T38FaxMaxBuffer:200..a=T38FaxMaxData
gram:72..a=T38FaxUdpEC:t38UDPRedundancy..
#
U 10.0.0.19:5060 -> 10.0.0.67:5060
SIP/2.0 100 Trying..Via: SIP/2.0/UDP 10.0.0.67:5060..From:
<sip:1234@proxy.com;user=
phone>;tag=48235ADC-1DB8..To:
<sip:55519@proxy.com;user=phone>;tag=2482904200..Call-ID: 13
7792672@10.0.0.35..CSeq: 101 INVITE..Server: Sip Router..Content-Length: 0....
#
====The INVITE sent to the ATA has only one route header======
U 10.0.0.19:5060 -> 10.0.0.18:5071
INVITE sip:1234@10.0.0.18:5071 SIP/2.0..Record-Route:
<sip:1234@10.0.0.19;ftag=48235ADC-1DB8;lr>
..Via: SIP/2.0/UDP 10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..Via: SIP/2.0/UDP
10.0.0.67:5060..Fr
om: <sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To:
<sip:55519@proxy.com;user=phone>;
tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12 GMT..Call-ID:
137792672@10.0.0.35..Route
: <sip:55519@10.0.0.18:5071;user=phone>..Supported: timer,100rel..Min-SE:
1800..Cisco-Guid: 10539524
64-397283801-2441193380-2221309272..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow:
INVITE, OPTIONS, BYE, CA
NCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO..CSeq: 101 INVITE..Max-Forwards:
5..Remote-Party-I
D: <sip:55519@10.0.0.67>;party=calling;screen=no;privacy=off..Timestamp:
1097163732..Contact: <sip:74
7%23555133280636@10.0.0.67:5060>..Expires: 180..Allow-Events:
telephone-event..Content-Type: applicat
ion/sdp..Content-Length: 402....v=0..o=CiscoSystemsSIP-GW-UserAgent 8783 1168 IN IP4
10.0.0.67..s=SIP
Call..c=IN IP4 10.0.0.67..t=0 0..m=image 18742 udptl t38..c=IN IP4
10.0.0.67..a=T38FaxVersion:0
..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0..a=T38FaxTranscodingJBIG:0..a=
T38FaxRateManagement:transferredTCF..a=T38FaxMaxBuffer:200..a=T38FaxMaxDatagram:72..a=T38FaxUdpEC:t38UDPRe
dundancy..
#
U 10.0.0.18:5071 -> 10.0.0.19:5060
SIP/2.0 488 Not Acceptable Here..Via: SIP/2.0/UDP
10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..Via: SIP/2
.0/UDP 10.0.0.67:5060..From:
<sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To: <
sip:55519@proxy.com;user=phone>;tag=2482904200..Call-ID: 137792672@10.0.0.35..CSeq:
101 IN
VITE..timestamp: 1097163732..server: Cisco ATA 186 v3.1.0 atasip (040211A)..warning:
Media type not avail
able..Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER..Content-Length:
0....
#
===========The ACK sent to ATA has two route headers, and the top route header is the same
as the R-Uri.
===========Is this correct?
U 10.0.0.19:5060 -> 10.0.0.18:5071
ACK sip:1234@10.0.0.18:5071 SIP/2.0..Via: SIP/2.0/UDP
10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..F
rom: <sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..Call-ID:
137792672@10.0.0.35..To:
<sip:55519@proxy.com;user=phone>;tag=2482904200..CSeq: 101 ACK..Route:
<sip:1234@10.0.0.18:5071>,
<sip:55519@10.0.0.18:5071;user=phone>..User-Agent: Sip Router..Content-Length
: 0....
#
U 10.0.0.19:5060 -> 10.0.0.67:5060
SIP/2.0 488 Not Acceptable Here..Via: SIP/2.0/UDP 10.0.0.67:5060..From:
<sip:1234@proxy.com;user=phone>;
tag=48235ADC-1DB8..To: <sip:55519@proxy.com;user=phone>;tag=2482904200.
.Call-ID: 137792672@10.0.0.35..CSeq: 101 INVITE..timestamp: 1097163732..server: Cisco
ATA 186 v3.1.0 atas
ip (040211A)..warning: Media type not available..Allow: ACK, BYE, CANCEL, INVITE,
NOTIFY, OPTIONS, REFER,
REGISTER..Content-Length: 0....
#
===========Supposing that this ACK was not absorved by the proxy, what would be the
behavior of loose_route()?
===========Wouldn't loose_route change the R-URI by the topmost router and then remove
it? If so, this ACK
===========would be equal to the one previously sent by ser but it would have only one
route header. Am I missing
===========something?
U 10.0.0.67:50549 -> 10.0.0.19:5060
ACK sip:1234@10.0.0.19:5060;ftag=2482904200;lr SIP/2.0..Via: SIP/2.0/UDP
10.0.0.67:5060..From:
<sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To:
<sip:55519@proxy.com;user=phone>;
tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12 GMT..Call-ID:
137792672@10.0.0.35..Route: <s
ip:1234@10.0.0.18:5071>, <sip:55519@10.0.0.18:5071;user=phone>..Max-Forwards:
6..Content-Length:
0..CSeq: 101 ACK....
#
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
13 Oct
13 Oct
7:04 p.m.
Thanks for your explanation Bogdan,
but don't you think that the local ACK should be
generated according the RE-INVITE that was sent by SER
instead of the one received by SER?
In this way the local ACK would be the same as if SER
has processed the ACK generated by the endpoint!
Regards,
Chuck.
--- Bogdan-Andrei IANCU <iancu(a)fokus.fraunhofer.de>
wrote:
0.175.202.67..a=T38FaxVersion:0..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0
..a=T38FaxTranscodingJBIG:0..a=T38FaxRateManagement:transferredTCF..a=T38FaxMaxBuffer:200..a=T38FaxMaxData
<sip:55519@proxy.com;user=phone>;tag=2482904200..Call-ID:
..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0..a=T38FaxTranscodingJBIG:0..a=
T38FaxRateManagement:transferredTCF..a=T38FaxMaxBuffer:200..a=T38FaxMaxDatagram:72..a=T38FaxUdpEC:t38UDPRe
<sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To:
> <
sip:55519@proxy.com;user=phone>;tag=2482904200..Call-ID:
<sip:55519@proxy.com;user=phone>;tag=2482904200..CSeq:
As described in RFC 3261, section 12.2 Requests
within a Dialog :
"Requests within a dialog MAY contain Record-Route
and Contact header
fields. However, these requests do not cause the
dialog's route set to
be modified, although they may modify the remote
target URI."
As the GW uses for the re-INVITE the route set
learned via original
INVITE (there are 2 Route hdr in your re-INVITE),
SER follows the same
principal and when generating the ACK, instead of
using the RR from
re_INVITE reply, it uses also the Route set from
RE-INVITE.
Anyhow, as you can see, the 488 reply doen't mirror
at all the RR set,
since the .18 device knows that is a reply for a
re-INVITE and the ROUTE
set is already established.
bogdan
Chuck Ramirez wrote:
<sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To:
Hello guys,
I'm trying to understand what is happening with SER
and re-INVITEs (for T.38 fax).
I have the follwing scenario:
ATA -> Session Border(NAT) -> SER -> Cisco Gateway
The ATA connects to the Cisco gateway for a voice
call
and when the gateway receives a fax tone is starts
a
re-INVITE to try to negotiate T38 parameters. Then
ATA
responds with 488 Not Supported Here and SER sends
a
ACK back to the ATA before sending 488 to the
gateway.
In this ACK it seems that SER is adding an extra
route
header as the INVITE that was sent to the ATA had
only
one route header. Why SER is adding two route
headers?
I'm attaching ngrep logs to this mail (with some
further comments), where:
The IP 10.0.0.19 is the Proxy
The IP 10.0.0.67 is the gateway
The IP 10.0.0.18 is the Session Border (NAT)
Thanks in advance,
Chuck.
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
------------------------------------------------------------------------
#
U 10.0.0.67:50549 -> 10.0.0.19:5060
INVITE sip:1234@10.0.0.19:5060;ftag=2482904200;lr
SIP/2.0..Via: SIP/2.0/UDP
10.0.0.67:5060..Fro
m:
<sip:55519@proxy.com;user=phone>;
1053952464-397283801-2441193380-2221309272..User-Agent:
tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12
GMT..Call-ID: 137792672@10.0.0.35..Route:
<sip:1234@10.0.0.18:5071>,
<sip:55519@10.0.0.18:5071;user=phone>..Supported:
timer,100rel..Min-
SE: 1800..Cisco-Guid:
Cisco-SIPGateway/IOS-12.x..
<sip:55519@10.0.0.67>;party=calling;screen=no;privacy=off..Timestam
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK,
COMET, REFER, SUBSCRIBE, NOTIFY, INFO..CSeq: 101
INVITE..
Max-Forwards: 6..Remote-Party-ID:
p:
1097163732..Contact:
<sip:747%23555133280636@10.0.0.67:5060>..Expires:
180..Allow-Events: telephon
e-event..Content-Type:
application/sdp..Content-Length:
402....v=0..o=CiscoSystemsSIP-GW-UserAgent 8783 11
68 IN IP4 10.0.0.67..s=SIP Call..c=IN IP4
10.0.0.67..t=0 0..m=image 18742 udptl t38..c=IN IP4
20
gram:72..a=T38FaxUdpEC:t38UDPRedundancy..
#
U 10.0.0.19:5060 -> 10.0.0.67:5060
SIP/2.0 100 Trying..Via: SIP/2.0/UDP
10.0.0.67:5060..From:
<sip:1234@proxy.com;user=
phone>;tag=48235ADC-1DB8..To:
13
<sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..To:
7792672@10.0.0.35..CSeq: 101 INVITE..Server:
Sip
Router..Content-Length: 0....
#
====The INVITE sent to the ATA has only one route
header======
U 10.0.0.19:5060 -> 10.0.0.18:5071
INVITE sip:1234@10.0.0.18:5071
SIP/2.0..Record-Route:
<sip:1234@10.0.0.19;ftag=48235ADC-1DB8;lr>
..Via: SIP/2.0/UDP
10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..Via:
SIP/2.0/UDP 10.0.0.67:5060..Fr
om:
<sip:55519@proxy.com;user=phone>;
<sip:55519@10.0.0.67>;party=calling;screen=no;privacy=off..Timestamp:
> 1097163732..Contact: <sip:74
> > 7%23555133280636@10.0.0.67:5060>..Expires:
> 180..Allow-Events: telephone-event..Content-Type:
> applicat
> > ion/sdp..Content-Length:
> 402....v=0..o=CiscoSystemsSIP-GW-UserAgent 8783 1168
> IN IP4 10.0.0.67..s=SIP
> > Call..c=IN IP4 10.0.0.67..t=0 0..m=image 18742
> udptl t38..c=IN IP4 10.0.0.67..a=T38FaxVersion:0
tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12
GMT..Call-ID: 137792672@10.0.0.35..Route
:
<sip:55519@10.0.0.18:5071;user=phone>..Supported:
timer,100rel..Min-SE: 1800..Cisco-Guid: 10539524
64-397283801-2441193380-2221309272..User-Agent:
Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS,
BYE, CA
NCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE,
NOTIFY, INFO..CSeq: 101 INVITE..Max-Forwards:
5..Remote-Party-I
D:
dundancy..
#
U 10.0.0.18:5071 -> 10.0.0.19:5060
SIP/2.0 488 Not Acceptable Here..Via: SIP/2.0/UDP
10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..Via: SIP/2
.0/UDP 10.0.0.67:5060..From:
137792672@10.0.0.35..CSeq: 101 IN
<sip:1234@proxy.com;user=phone>;tag=48235ADC-1DB8..Call-ID:
> 137792672@10.0.0.35..To:
VITE..timestamp: 1097163732..server: Cisco ATA
186 v3.1.0 atasip (040211A)..warning: Media type
not avail
able..Allow: ACK, BYE, CANCEL, INVITE, NOTIFY,
OPTIONS, REFER, REGISTER..Content-Length: 0....
#
===========The ACK sent to ATA has two route
headers, and the top route header is
the same as the
R-Uri.
===========Is this correct?
U 10.0.0.19:5060 -> 10.0.0.18:5071
ACK sip:1234@10.0.0.18:5071 SIP/2.0..Via:
SIP/2.0/UDP
10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..F
rom:
101 ACK..Route: <sip:1234@10.0.0.18:5071>,
<sip:55519@10.0.0.18:5071;user=phone>..User-Agent:
=== message truncated ===
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
http://messenger.yahoo.com
7357
days inactive
7363
days old
2 comments
2 participants
participants (2)
-
Bogdan-Andrei IANCU -
Chuck Ramirez