i did more tests, this time without canceling the call. i noticed that sbc is using incorrect route header in in-dialog requests.
in a-scb-b case, when a sends invite to b, 200 ok that sems receives from b has this kind of r-r header: Record-Route: <sip:192.98.102.10;r2=on;lr;ftag=01C74A18-4DC40A7F0001F6F1-B5BFCB70>,<sip:127.0.0.1:5080;r2=on;lr;ftag=01C74A18-4DC40A7F0001F6F1-B5BFCB70> when a sends bye to b, bye from sems to b contains this kind of route header: Route: <sip:127.0.0.1:5080;lr>,<sip:127.0.0.1:5080;r2=on;lr;ftag=01C74A18-4DC40A7F0001F6F1-B5BFCB70>, <sip:192.98.102.10;r2=on;lr;ftag=01C74A18-4DC40A7F0001F6F1-B5BFCB70> i'm pretty sure that rfc3261 says that in in-dialog requests, route header must contain in reverse order the entries learned from 200 ok that established the dialog. in the above example, the first entry is extra. it seems to be the pre-set one of sems' outbound proxy. -- juha _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
