Hi Alex,
That's a very good point you are making. Filtering out the header might
not be enough.
On 07.10.10 23:40, Alex Balashov wrote:
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?
Or are you passing along the reinvite as some kind of optimisation of
convenience / to simplify code?
The B2BUA in SEMS is by default trying to be very transparent. This is
means that we try to let the real endpoints talk together, without touch
too much of the signaling. This is the general rule.
In the case you are describing, we have an INVITE which is sent as part
of the session timer mechanism. Should we forward it, or absorb it? By
the way, I believe we have the same issue with UPDATE.
If we decide to absorb the request: how do we recognize that a request
should be handled locally, and should thus not be forwarded?
The RFC documents cannot help us here, as the B2BUA case has always been
out-of-scope.
In RFC 4028, section 7.4, it says:
"A re-INVITE generated to refresh the session is a normal re-INVITE,
and an UPDATE generated to refresh a session is a normal UPDATE."
However, if we cannot differentiate the session refresh request from the
others, we will have to continue relaying those requests. And we are
back at filtering out the headers...
Any other thoughts/proposals for solving the problem?
Cheers
Raphael.
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
