On 08.10.10 12:47, Alex Balashov wrote:
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.
After some more thoughts, I think the only thing we can do is to remove
"timer" from the "Require" HF when we know that the other side does not
support it.
The interesting question is whether or not we could work-around the
problem by adding "refresher=uac" in the first INVITE. I'm curious to
know whether Asterisk would then still place a "Require" header in a
subsequent request. But how to trigger that request, if Asterisk is not
refresher??
Cheers
Raphael.
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.
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
