it turned out that after the order of route headers was fixed, also the
ack problem went away. the reason is that before the fix, 200 ok that
sems received from A had incorrect contact uri because openser had not
properly rewritten it. the reason why openser didn't properly rewrite
the contact was because wrong route header didn't contain proper
parameters.
now re-invite is correct like this:
Request-Line: INVITE sip:[EMAIL PROTECTED]:59497 SIP/2.0
Via: SIP/2.0/UDP 192.98.101.10:5090;branch=z9hG4bK1c11ta~W
Route: <sip:192.98.101.10;r2=on;lr>
Route: <sip:192.98.101.10:5070;r2=on;lr>
Route: <sip:192.98.101.10;lr;n1;dm>
From: <sip:[EMAIL PROTECTED]>;tag=4217F460-4805A748000C8945-B6CFDB90
To: "Juha Heinanen" <sip:[EMAIL PROTECTED]>;tag=dstla
CSeq: 10 INVITE
Call-ID: [EMAIL PROTECTED]
Contact: <sip:[EMAIL PROTECTED]:5090>
...
and when 200 ok comes back to sems, it is correct like this:
Status-Line: SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.98.101.10:5090;branch=z9hG4bK1c11ta~W
To: "Juha Heinanen" <sip:[EMAIL PROTECTED]>;tag=dstla
From: <sip:[EMAIL PROTECTED]>;tag=4217F460-4805A748000C8945-B6CFDB90
Call-ID: [EMAIL PROTECTED]
CSeq: 10 INVITE
Contact: <sip:[EMAIL PROTECTED]:59497>
...
sems then sends ack that is missing route headers, but is otherwise ok:
Request-Line: ACK sip:[EMAIL PROTECTED]:59497 SIP/2.0
Via: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bKNc11taCe
From: <sip:[EMAIL PROTECTED]>;tag=4217F460-4805A748000C8945-B6CFDB90
To: "Juha Heinanen" <sip:[EMAIL PROTECTED]>;tag=dstla
Call-ID: [EMAIL PROTECTED]
Max-Forwards: 10
CSeq: 10 ACK
the reason this ack works is because my openser config handles acks hop
by hop and thus not need the route headers.
so looks like in my environment, i don't need the hack to fix the ack to
re-invite.
-- juha
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
