Of course, this discussion revolves around the premise that you intend
SEMS to continue to be a "thin" / "transparent" B2UA that mostly
passes requests and replies unadulterated, except in the ways required
for distinct logical call legs (distinct branch ID, Call-ID, CSeq
number, From and To tags, etc.). I assume that's true.
But just theoretically, one could make the argument that the SST B2BUA
should be an "opaque" B2BUA: it should absorb every sequential
request by default, completely isolate the states of the two call
legs, and explicitly bridge only certain kinds of requests and replies
between the call legs, like negative final responses, BYEs, etc.
The mess that this gets you into is negotiation. What if one endpoint
sends a legitimate reinvite to change codecs, say, and SEMS is always
the logical endpoint of such a request? What should it do, especially
if media is not flowing through it? I imagine this and code-level
constraints is the heart of the reason why you went for the
transparent B2BUA option instead.
--
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
