Hi Klaus!
Thanks for the hint! Indeed looking into the vsf=xxx parameter a little bit closer, I found out, that on the reInvite the uac_replace() is done due to the Route: vsf=xxx Param (knew that :-), but the vsf=xxx is not added again on to the Record-Route (missed that :-). So the 2nd 200 OK doesn't contain it in the route-set anymore, thus the following ACK doesn't have it in the Route Header.
Is it up to me to add it to Record-Route Header, if the Route Header contains these parameters? Shouldn't the uac_replace() do that on replacing the From again?
Let's see, what I can do here.
Br Walter
-----Ursprüngliche Nachricht----- Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Dienstag, 25. November 2008 18:04 An: Schober Walter Cc: users@lists.kamailio.org Betreff: Re: [Kamailio-Users] UAC on ACK in reInvite
Hi Walter!
Automatic restoring uses record route parameters to store the original from URI. Maybe there is something wrong with the RR header.
I can not remember any changes in UAC module, thus I am not sure if an update will help you.
regards klaus
Schober Walter wrote:
Hello All!
Tried to fix that anyhow but without success yet. Anyone who could just tell me, if it's fixed in 1.4.something?
Scenario: A -> Openser 1.1.1 -> Openser 1.1.1 -> Openser 1.1.1 (UAC:normalize From to phone number in national format) -> B
A Invites B => all OK A reInvites B with T.38 -> INVITE => OK <- 200 OK => OK -> ACK => From field not handled by UAC.
UAC config all default, so UAC restore mode "auto". Neither INVITE nor ACK get's uac_replace'd in if(loose_route()) block, but INVITE get's handled properly.
Upgrading to 1.4 or 1.3 is risky - or is it not? ;-) - because never touch a running system, isn't it? But then that customer comes with that Allied Telesis CPE :-) (And Ati blames the proxy for not matching the ACK in the CPE although they use a from-tag, too).
Many Thanks! br Walter
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Schober Walter wrote:
Hi Klaus!
Thanks for the hint! Indeed looking into the vsf=xxx parameter a little bit closer, I found out, that on the reInvite the uac_replace() is done due to the Route: vsf=xxx Param (knew that :-), but the vsf=xxx is not added again on to the Record-Route (missed that :-). So the 2nd 200 OK doesn't contain it in the route-set anymore, thus the following ACK doesn't have it in the Route Header.
This is clearly a bug in the useragent. The route set must not be changed with reINVITEs. Thus, according to the standard the Record-Route headers for indialog requests are not needed. Maybe you are calling record_route() for indialog requests and this confuses the client.
Try removing the record_route() for indialog requests - may then the buggy client remembers the original route set.
regards klaus
Is it up to me to add it to Record-Route Header, if the Route Header contains these parameters? Shouldn't the uac_replace() do that on replacing the From again?
Let's see, what I can do here.
Br Walter
-----Ursprüngliche Nachricht----- Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Dienstag, 25. November 2008 18:04 An: Schober Walter Cc: users@lists.kamailio.org Betreff: Re: [Kamailio-Users] UAC on ACK in reInvite
Hi Walter!
Automatic restoring uses record route parameters to store the original from URI. Maybe there is something wrong with the RR header.
I can not remember any changes in UAC module, thus I am not sure if an update will help you.
regards klaus
Schober Walter wrote:
Hello All!
Tried to fix that anyhow but without success yet. Anyone who could just tell me, if it's fixed in 1.4.something?
Scenario: A -> Openser 1.1.1 -> Openser 1.1.1 -> Openser 1.1.1 (UAC:normalize From to phone number in national format) -> B
A Invites B => all OK A reInvites B with T.38 -> INVITE => OK <- 200 OK => OK -> ACK => From field not handled by UAC.
UAC config all default, so UAC restore mode "auto". Neither INVITE nor ACK get's uac_replace'd in if(loose_route()) block, but INVITE get's handled properly.
Upgrading to 1.4 or 1.3 is risky - or is it not? ;-) - because never touch a running system, isn't it? But then that customer comes with that Allied Telesis CPE :-) (And Ati blames the proxy for not matching the ACK in the CPE although they use a from-tag, too).
Many Thanks! br Walter
_______________________________________________ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-
Klaus Darilion -
Schober Walter