[Serusers] ACK for non-2XX not record-routed

Emmanuel Hislen hislen at alcatel-lucent.com
Fri Mar 16 19:38:57 CET 2007


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.



More information about the sr-users mailing list