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

[Miklos Tirpak]

Hello,

comments inline

On 03/20/2007 09:52 AM, Greger V. Teigre wrote:
> 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.

just to make some definition clear: Route set is the collection of Route 
headers, the Record-route headers are used only to learn the route-set. 
So the missing Record-route header does not have any impact of the ACK 
routing, however could have an impact of routing the BYE for example in 
your case. But the RFC says that the in-dialog requests do not modify 
the previously learned route-set:

"12.2 Requests within a Dialog
...
    Requests within a dialog MAY contain Record-Route and Contact header
    fields.  However, these requests do not cause the dialog's route set
    to be modified, although they may modify the remote target URI.
    Specifically, requests that are not target refresh requests do not
    modify the dialog's remote target URI, and requests that are target
    refresh requests do.  For dialogs that have been established with an
    INVITE, the only target refresh request defined is re-INVITE (see
    Section 14).  Other extensions may define different target refresh
    requests for dialogs established in other ways.

       Note that an ACK is NOT a target refresh request."

But be careful with modifying the route-set in SER (not with 
record-routeing but with modifying the route headers directly)!
More info: http://tracker.iptel.org/browse/SER-212?page=all

Regards,
Miklos

>>
>>
>> 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 at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers