Hi Alex,
On 08.10.10 13:33, Alex Balashov wrote:
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.
Right, that's true for the core classes (AmB2BSession, AmB2ABSession).
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.
Once you have figured out how "opaque" or "transparent" you want your
B2BUA to be, you can implement those policies very easily in SEMS. It is
only about filtering the flow of messages passed from side to the other.
Most commercial SBCs are quite configurable when it comes to "opacity".
In my opinion, a B2BUA should be as transparent as possible, so that it
allows for new applications to be deployed on the endpoints without
requiring specific support in the network. This is also the idea behind
a SIP proxy ;-)
Cheers
Raphael.
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
