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