i studied the a2bua ack problem again and it seems to me that route
headers in re-invite that sems sends to a are in wrong order.
when sems receives initial invite from a, its r-uri and r-r headers look
like this:
Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0
Message Header
Record-Route: <sip:192.98.101.10;r2=on;lr>
Record-Route: <sip:192.98.101.10:5070;r2=on;lr>
Record-Route: <sip:192.98.101.10;lr;n1;dm>
according to rfc 3261 section 12.1.1 UAS behavior (Creation of Dialog):
The route set MUST be set to the list of URIs in the Record-Route header
field from the request, taken in order and preserving all URI parameters.
so route set at sems becomes:
<sip:192.98.101.10;r2=on;lr>,<sip:192.98.101.10:5070;r2=on;lr>,
<sip:192.98.101.10;lr;n1;dm>
when sems sends re-invite to a, it looks like this:
Request-Line: INVITE sip:[EMAIL PROTECTED]:59365 SIP/2.0
Message Header
Route: <sip:192.98.101.10;lr;n1;dm>
Route: <sip:192.98.101.10:5070;r2=on;lr>
Route: <sip:192.98.101.10;r2=on;lr>
i.e., sems has reversed the order r-r headers when it has turned them to
route headers.
according to 12.2.1 UAC Behavior (Requests within a Dialog):
If the route set is not empty, and the first URI in the route set
contains the lr parameter (see Section 19.1.1), the UAC MUST place the
remote target URI into the Request-URI and MUST include a Route header
field containing the route set values in order, including all
parameters.
unless i'm missing something (which is always possible), route headers
in re-invite from sems to a are in incorrect order.
-- juha
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
