8 Oct
2004
8 Oct
'04
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