25 Aug
2008
25 Aug
'08
11:08 a.m.
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(a)in.ilimit.es