You raise a compelling point.
I suppose the only thing I can come up with is to check if the SDP
version, content, or sequential target URI (Contact) have changed. If
they have not, perhaps one can assume it is an SST-only reinvite.
However, I imagine this is not an adequate criterion. What if there
are other entities present in the call path that also do SST
refreshes, or have other reasons for sending a reinvite whose body
does not superficially differ from the previous one (e.g. it just
happens to be, but could be different in principle).
I think you're right. After further reflection, there's not much you
can do but propagate sequential requests more or less transparently.
On 10/08/2010 04:48 AM, Raphael Coeffic wrote:
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.
--
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
