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 ;)