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.... #
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@fokus.fraunhofer.de wrote:
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: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:
=== message truncated ===
__________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com
-
Bogdan-Andrei IANCU -
Chuck Ramirez