15 Feb
2004
15 Feb
'04
9:46 p.m.
Hi,
I do have the following situation:
UA1 calls UA2 going through ser 0.8.12. All signaling is Recourd Routed and
go through ser.
UA2 doesn't answer and I do have a t_on_failure to go to UA3.
UA3 receives INVITES from ser, and answer with a 200/OK with sdp, this
messages goes through ser which forward it to UA1.
UA1 sends an ACK to ser having this in message:
Session Initiation Protocol
Request line: ACK sip:ua3@22.2.4.193:5071 SIP/2.0
Method: ACK
Message Header
Via: SIP/2.0/UDP 2.20.64.193:5063;branch=z9hG4bk-7f415771
From: test1 <sip:ua1@vocal.ipsound.net>;tag=eb646133bf338b12
To: <sip:ua2@vocal.ipsound.net>;tag=as47221fa0
Call-ID: a66804e6-5ac924fd(a)142.133.80.102
CSeq: 102 ACK
Max-Forwards: 70
Route: <sip:sip-proxy@ser-domain.com;ftag=eb646133bf338b12;lr=on>
Proxy-Authorization: Digest username="
Contact: ua1 <sip:ua1@24.202.64.193:5063>
User-Agent: Sipura/SPA2000-1.0.10
Content-Length: 0
Ser is supposed to follow the route, and ends up looking into the location
table and re-forwards the request to UA2 again (even if it already timed out
once).
Now I do have another UA which in this same scenario sends the correct ACK:
Session Initiation Protocol
Request line: ACK sip:sip-proxy@ser-domain.com SIP/2.0
Method: ACK
Message Header
Route: <sip:ua3@22.2.4.193:5071>
Via: SIP/2.0/UDP 2.20.64.193:5063
From: ua1 <sip:ua1@ser-domain.com;user=phone>;tag=3551608275
To: <sip:ua2@ser-domain.com;user=phone>;tag=as112d04ea
Call-ID: 2653016335(a)142.133.80.101
CSeq: 2 ACK
User-Agent: Cisco ATA 186 v3.0.0 atasip (031210A)
Proxy-Authorization: Digest username
Content-Length: 0
In this case ser follow the route header, and ends up sending the ACK to
UA3.
Snom phone with 2.03o firmware as well as sipura with 1.0.10 and 1.0.29b
firmware have the same wrong behaviour.
What is the right way of having this ?
My understanding is that in record route situation, ser looks into the route
header, and sends the message based on it. Here I do have User Agents which
seem to create an ACK message ignoring it should go to a sip proxy .
Am I missing something here ?
Thanks.
Samy.
15 Feb
15 Feb
10:42 p.m.
At 08:46 PM 2/15/2004, Samy Touati wrote:
Hi,
I do have the following situation:
UA1 calls UA2 going through ser 0.8.12. All signaling is Recourd Routed and go through
ser.
UA2 doesn�t answer and I do have a t_on_failure to go to UA3.
UA3 receives INVITES from ser, and answer with a 200/OK with sdp, this messages goes
through ser which forward it to UA1.
UA1 sends an ACK to ser having this in message:
Session Initiation Protocol
Request line: ACK sip:ua3@22.2.4.193:5071 SIP/2.0
Method: ACK
Message Header
Via: SIP/2.0/UDP 2.20.64.193:5063;branch=z9hG4bk-7f415771
From: test1 <sip:ua1@vocal.ipsound.net>;tag=eb646133bf338b12
To: <sip:ua2@vocal.ipsound.net>;tag=as47221fa0
Call-ID: a66804e6-5ac924fd(a)142.133.80.102
CSeq: 102 ACK
Max-Forwards: 70
Route: <sip:sip-proxy@ser-domain.com;ftag=eb646133bf338b12;lr=on>
Proxy-Authorization: Digest username="
Contact: ua1 <sip:ua1@24.202.64.193:5063>
User-Agent: Sipura/SPA2000-1.0.10
Content-Length: 0
Ser is supposed to follow the route, and ends up looking into the location table and
re-forwards the request to UA2 again (even if it already timed out once).
Interesting -- it looks like properly generated ACK, except the URI in Route
has some strange value -- I mean SER generates the URI as
sip:<username_from_INVITE>@<SER_IP>;ftag=...
How did these values appear there?
Are you sure your script does include the initial if (loose_route) { t_relay();break; }
sequence? That should forward the request to address in request URI.
Now I do have another UA which in this same scenario
sends the correct ACK:
Session Initiation Protocol
Request line: ACK sip:sip-proxy@ser-domain.com SIP/2.0
Method: ACK
Message Header
Route: <sip:ua3@22.2.4.193:5071>
Via: SIP/2.0/UDP 2.20.64.193:5063
From: ua1 <sip:ua1@ser-domain.com;user=phone>;tag=3551608275
To: <sip:ua2@ser-domain.com;user=phone>;tag=as112d04ea
Call-ID: 2653016335(a)142.133.80.101
CSeq: 2 ACK
User-Agent: Cisco ATA 186 v3.0.0 atasip (031210A)
Proxy-Authorization: Digest username
Content-Length: 0
In this case ser follow the route header, and ends up sending the ACK to UA3.
Snom phone with 2.03o firmware as well as sipura with 1.0.10 and 1.0.29b firmware have the
same wrong behaviour.
What is the right way of having this ?
The problem with snom may be the phone uses some preloaded Routes
which are incompatible with some record-routing workaround for a Cisco
gateway problem in SER. I remember it was reported on the archive --
you perhaps find more there.
My understanding is that in record route situation, ser
looks into the route header, and sends the message based on it.
yes
Here I do have User Agents which seem to create an ACK
message ignoring it should go to a sip proxy .
You told above UA1 does send to proxy, did not you? It would be better to
send a complete message dump and config file.
-jiri
11:11 p.m.
Hi,
Yes UA1 does send an ACK to ser, but the request URI contains the address of
UA3 and the route heard contains the address of ser. With this scenario, ser
routes the request to the initial called UA (UA2) instead of going to UA3.
The second ACK message still coming from UA1 (but a different UA, ATA186 in
this case) does generate an ACK but in the request URI it's the ser proxy
address, and in the route header it's the address of UA3, and in this case
ser route the ACK to UA3.
In both cases the ACK is generated from UA1 (but they are different brands)
and they go to ser.
Included are two ethereal files, one is redirect-fail which contain the
redirection to a host @ port 5071 (UA3) while the second one redirect-ok
still contain the same redirect but this time it's working.
Phoenix.tunix.com:5071 is the address of UA3 (asterisk).
Thanks.
Samy.
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Sunday, February 15, 2004 3:42 PM
To: Samy Touati; serusers(a)lists.iptel.org
Subject: Re: [Serusers] UAs not respecting Record Route
At 08:46 PM 2/15/2004, Samy Touati wrote:
Hi,
I do have the following situation:
UA1 calls UA2 going through ser 0.8.12. All signaling is Recourd Routed and
go
through ser.
UA2 doesnt answer and I do have a t_on_failure to go
to UA3.
UA3 receives INVITES from ser, and answer with a 200/OK with sdp, this
messages goes
through ser which forward it to UA1.
UA1 sends an ACK to ser having this in message:
Session Initiation Protocol
Request line: ACK sip:ua3@22.2.4.193:5071 SIP/2.0
Method: ACK
Message Header
Via: SIP/2.0/UDP 2.20.64.193:5063;branch=z9hG4bk-7f415771
From: test1 <sip:ua1@vocal.ipsound.net>;tag=eb646133bf338b12
To: <sip:ua2@vocal.ipsound.net>;tag=as47221fa0
Call-ID: a66804e6-5ac924fd(a)142.133.80.102
CSeq: 102 ACK
Max-Forwards: 70
Route: <sip:sip-proxy@ser-domain.com;ftag=eb646133bf338b12;lr=on>
Proxy-Authorization: Digest username="
Contact: ua1 <sip:ua1@24.202.64.193:5063>
User-Agent: Sipura/SPA2000-1.0.10
Content-Length: 0
Ser is supposed to follow the route, and ends up looking into the location
table and
re-forwards the request to UA2 again (even if it already timed out
once).
Interesting -- it looks like properly generated ACK, except the URI in Route
has some strange value -- I mean SER generates the URI as
sip:<username_from_INVITE>@<SER_IP>;ftag=...
How did these values appear there?
Are you sure your script does include the initial if (loose_route) {
t_relay();break; }
sequence? That should forward the request to address in request URI.
Now I do have another UA which in this same scenario
sends the correct ACK:
Session Initiation Protocol
Request line: ACK sip:sip-proxy@ser-domain.com SIP/2.0
Method: ACK
Message Header
Route: <sip:ua3@22.2.4.193:5071>
Via: SIP/2.0/UDP 2.20.64.193:5063
From: ua1 <sip:ua1@ser-domain.com;user=phone>;tag=3551608275
To: <sip:ua2@ser-domain.com;user=phone>;tag=as112d04ea
Call-ID: 2653016335(a)142.133.80.101
CSeq: 2 ACK
User-Agent: Cisco ATA 186 v3.0.0 atasip (031210A)
Proxy-Authorization: Digest username
Content-Length: 0
In this case ser follow the route header, and ends up sending the ACK to
UA3.
Snom phone with 2.03o firmware as well as sipura with 1.0.10 and 1.0.29b
firmware
have the same wrong behaviour.
What is the right way of having this ?
The problem with snom may be the phone uses some preloaded Routes
which are incompatible with some record-routing workaround for a Cisco
gateway problem in SER. I remember it was reported on the archive --
you perhaps find more there.
My understanding is that in record route situation, ser
looks into the
route header, and sends the message based on it.
yes
Here I do have User Agents which seem to create an ACK
message ignoring it
should go to a sip proxy .
You told above UA1 does send to proxy, did not you? It would be better to
send a complete message dump and config file.
-jiri
16 Feb
16 Feb
1:04 a.m.
At 10:11 PM 2/15/2004, Samy Touati wrote:
Hi,
Yes UA1 does send an ACK to ser, but the request URI contains the address of
UA3
and the route heard contains the address of ser.
Samy,
that's all ok too since the UAC is loose router (you find more information
in RFC3261; the basic concept of loose routing is not to stir target
address in request-uri with record-routing information). The other case
you referred to (proxy in r-uri, destination in Route) is ok too, it
is RFC2543 strict-routing UAC, whose messages should be routed eventually
the same way. That's probably the most confusing SIP issue.
With this scenario, ser
routes the request to the initial called UA (UA2) instead of going to UA3.
That's not ok -- I don't know yet why, it may be an error in SER: both the
ACK (frame #1151) and config files look reasonable to me, just the outgoing
ACK (frame #1155) is misconcepted somehow: 1) it includes wrong URI, 2)
transport destination is different from that inRoute in #1151 and 3) there
is no P_Hint at all (there should be some -- if you are using the script
you send me, there is append_hf(P-Hint) before each t_relay....) -- neither
does the forwarded INVITE (#513) include some which really surprises me.
Are you sure the message dumps were generating using exactly the same config
file you sent?
-jiri
(BTW -- better try to filter the traffic samples you send -- it is
ok if I filter the hundreds of messages to www.babycenter.com, but
you might have some privacy issues ;)
7587
days inactive
7587
days old
3 comments
2 participants
participants (2)
-
Jiri Kuthan -
Samy Touati