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