[Kamailio-Users] Having Problem routing an ACK

[Iñaki Baz Castillo]

El Monday 25 August 2008 16:41:37 Stagg Shelton escribió:
> == BEGIN ==
> The Request URI field is used for routing of initial dialog messages.  If
> state is not kept in [Open]SER by using the tm module, the SIP message can
> be routed based on the VIA or contact header, or worst case follow the same
> routing rules based on the original Request URIs, just like the original
> INVITE message did. == END ==

This make no sense *AT ALL*.
An ACK for a 200 OK is a **NEW** request (a new transaction). In case an ACK 
for a non 200 final response the ACK is part of the INVITE transaction but 
this is not the case.


> After some subsequent communication where I again questioned the way in
> which their system creates the ACK.  I received the below from them.
>
> == BEGIN ==
> All I was saying is that based on the way your system handles messages we
> send to it, your statement about changing the Request-URIs of ACKs based on
> values from the SDP of the 200 OK is not the case.

"changing the Request-URIs of ACKs based on values from the SDP of the 200 
OK" ???

What does he mean with "SDP"??? The only important to generate the route_set 
is the Contact of the "200 OK", no the SDP !!



> I believe that some 
> systems do however update the ACK’s Request-URI based on the Contact header
> field from the 200 response, but most system’s don’t route the ACK based on
> its Request-URI when keeping state.

It's their problem if some systems route the ACK for a 200 OK in some "exotic" 
way, but RFC3261 says *clearly* that an ACK for a 200 is a NEW request, an 
in-dialog request in fact, so the RURI of the ACK must be the remote target 
for the UAS that must be the "Contact" in the 200 OK.


Your provider behaviour is WRONG.
If they are not capable of fixing it I suggest you to add the "Contact" 
address also as a Record-Route parameter so you could get it from the 
top "Route" header in the wrong ACK from your provider.
Of course this is a hack, but worse is what yuor provider does.





-- 
Iñaki Baz Castillo
ibc at in.ilimit.es