I'm not sure that I understand what you mean is wrong. It would be
easier to follow if you include the ACKs. And non-2xxs, what is exactly
the exchange? A full SIP trace would help...
g-)
Emmanuel Hislen wrote:
Hi,
I've been using SER (0.9.6) as a Proxy doing Loose Routing between 2
endpoints.
If I place a call I can see how the ACK for the 2XX response to the
INVITE is properly handled (Route header removed, Record-Route inserted).
Now with the call still up, I do a re-INVITE which is rejected with a
415. The re-INVITE request sent by UAC contained a Route header, as it
was an in-dialog request in a record-routed dialog. Now as per RFC3261
section 17.1.1.3:
If the INVITE request whose response is being acknowledged had Route
header fields, those header fields MUST appear in the ACK. This is
to ensure that the ACK can be routed properly through any downstream
stateless proxies.
My UAC complied with the above, but SER seemed to choke on this:
whereas the ACK for 2XX was successfully routed by SER in the original
INVITE, the ACK for non-2XX (looking exactly the same: same Request
URI, same IP destination, same Route header, ... different Via branch
of course) is not handled properly: yes the ACK reaches UAS but it
still has the Route header in it, and no Record-Route was added. And
I'm guessing that if there had been another proxy in the Route Set on
the way to the UAS it would have been bypassed.
SER traces for ACK-2XX:
0(13574) ===> Loose Routing logic...
0(13574) parse_headers: flags=-1
0(13574) DEBUG: t_newtran: msg id=89 , global msg id=88 , T on
entrance=0xffffffff
0(13574) parse_headers: flags=-1
0(13574) parse_headers: flags=60
0(13574) t_lookup_request: start searching: hash=41794, isACK=1
0(13574) parse_headers: flags=28
0(13574) DEBUG: t_lookup_request: e2e proxy ACK found
0(13574) parse_headers: flags=4
0(13574) DEBUG: totag for e2e ACK found: 0
0(13574) SER: forwarding ACK statelessly
SER traces for ACK-non-2XX:
0(13574) ===> Loose Routing logic...
0(13574) parse_headers: flags=-1
0(13574) DEBUG: t_newtran: msg id=92 , global msg id=91 , T on
entrance=0xffffffff
0(13574) parse_headers: flags=-1
0(13574) parse_headers: flags=60
0(13574) t_lookup_request: start searching: hash=41807, isACK=1
0(13574) DEBUG: RFC3261 transaction matched, tid=007d7195499e33a1
0(13574) DEBUG: t_lookup_request: transaction found (T=0xb616ae48)
0(13574) DEBUG: cleanup_uac_timers: RETR/FR timers reset
0(13574) DEBUG: add_to_tail_of_timer[2]: 0xb616ae90
0(13574) DEBUG:destroy_avp_list: destroying list (nil)
0(13574) receive_msg: cleaning up
This doesn't seem right, am I missing something here?
Thanks,
Emmanuel.
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers