23 Apr
2010
23 Apr
'10
1:14 p.m.
On 23.04.10 11:58, Alex Balashov wrote:
On 04/23/2010 05:18 AM, Raphael Coeffic wrote:
RFC 3261 says on the topic (section 14.1):
"Of course, a UAC MAY send a re-INVITE with no session description,
in which case the first
reliable non-failure response to the re-INVITE will contain the offer
(in this specification, that is a 2xx response)."
On 23.04.10 09:51, Alex Balashov wrote:
I thought about empty INVITEs first, but my--admittedly naive--reading
of the specs suggests that many endpoints would take the absence of an
SDP offer/answer in a sequential request or reply within the same
session to mean that the media elements of the session have been
rescinded.
On 04/22/2010 10:01 AM, Stefan Sayer wrote:
]
Sending an empty INVITE has the appeal of working with either side (no
matter with which you begin). With the other, you might have to remember
which side initiated the last INVITE or UPDATE transaction, and send the
last positive SDP answer to this side as a re-INVITE. Or am I missing
something?
However, it might happen that the one of the ends does not support
receiving empty INVITEs... (less probable today). clean? I am not so sure any more, trying to hack
something together to
see where this gets. Is there a clean and simple method to do
re-invite
from the b2bua, which catches all the possibilities (changed session
etc)?
e.g., one possibility, reinvite with last SDP from the other side
From my understanding of SSTs, this is the correct approach (last
known SDP). This has the advantage of not breaking the changes of real
re-INVITEs that actually happened.
If I'm wrong, that would certainly make all this a
lot easier.
So I guess you MAY be wrong ;-)
Another question is: what would be the expire value you would like to
use for SST? This could dramatically change the requirements in terms of
load. Where you thinking about 15 minutes? (sending a re-INVITE approx.
every 7 minutes?) Or do you need a precise billing (maybe minute based?) ?
Cheers,
Raphael.