----- Original message ----- > I am more curious as to why the reinvite is being passed to the other > side. A reinvite is between two endpoints (a UAC and a UAS), right? > So when GW B sends a reinvite to SEMS, SEMS is the logical target of > that reinvite and should respond. This event may trigger SEMS to > generate a new and logically different reinvite to GW A, but it should > not have any direct causal relation to the reinvite received from GW B? >
when both legs are established, as you have seen the B2B in sems never absorbs incoming requests, but relays them all e2e. (The exception is when a session refresh initiated by SEMS is in progress, in that case a reinvite may be blocked (with error response and retry after)). I think this general rule saves us from potential issues and race conditions. Also, the relayed reinvite will do a refresh on the other side, with sdp and a whole sdp oa which is definitely a correct one; this is imo better than one initiated from the middle - if only that e2e reinvite does not need to be blocked for the duration of the refresh. Stefan > Or are you passing along the reinvite as some kind of optimisation of > convenience / to simplify code? > > Thanks, > > -- > Alex Balashov - Principal > Evariste Systems LLC > 1170 Peachtree Street > 12th Floor, Suite 1200 > Atlanta, GA 30309 > Tel: +1-678-954-0670 > Fax: +1-404-961-1892 > Web: http://www.evaristesys.com/ > _______________________________________________ > Sems mailing list > [email protected] > http://lists.iptel.org/mailman/listinfo/sems
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
