Hi,
o Emil Kroymann on 02/22/2012 12:32 PM:
Hi,
we had and solved a problem with the B2B*Session classes used via DSM.
Our DSM application connects to a caller either via dial in (incoming
initial INVITE) or dial out (SEMS sends the initial INVITE) and plays
some announcements and collects some DTMFS and then connects the call
to a second SEMS instance as B2BUA removing itself from the media path.
something does not add up here; the call flow graph is different from
what you decscribe.
The setup of the connection to the second SEMS instance was buggy and
had the following call flow before we patched SEMS.
Caller - SEMS 1 - SEMS 2
-- INVITE w/o SDP -->
<-- 200 OK w SDP --
-- ACK w SDP -->
<-- Re-INVITE w SDP --
-- 200 OK w SDP -->
<-- ACK w/o SDP --
-- Re-INVITE w SDP -->
<-- 200 OK w SDP --
-- ACK w/o SDP -->
As you can see, SEMS 1 sent an ACK to SEMS 2 with it's
own SDP before Re-INVITEing the caller to get the caller's
SDP. The problem with this call flow is, that the answer
from SEMS 2 is converted into an offer for the caller and
in the call flow above, it is actually an offer. that's why there's no
SDP in the INVITE to SEMS2, so that you can use an offer from SEMS2 to
reinvite the caller. But I'm actually wondering - is there really an
INVITE sent without SDP to SEMS2? looking at the code it would seem to
me that the original caller SDP would be sent to SEMS2
(invite_req.body is sent with the ConnectLeg event in ConnectCallee,
and then used in onB2BEvent).
Anyway, generally this call flow can work:
Caller - SEMS 1 - SEMS 2
-- INVITE w SDP -->
<-- 200 OK w SDP --
-- ACK -->
<-- Re-INVITE w SDP --
-- 200 OK w SDP -->
<-- ACK --
-- Re-INVITE w SDP -->
<-- 200 OK w SDP --
-- ACK -->
even if it converts an answer to an offer, and I would like to keep it
for the normal case that the callee (here SEMS2) does not support
delayed SDP negotiation; the offerless-invite call flow should be
optional I think.
Also, after a small look at the patch I think replacing the o-line can
be done at a more generic place - actually i think everywhere usually
the SDP filter is called. can you possibly split out this
functionality into a separate patch?
Thanks!
Stefan
the answer from the caller is converted into an offer
for SEMS 2, such that no correct offer/answer cycle between
caller and SEMS 2 is in effect.
We patched the B2B*Session classes to exhibit the following
call flow instead.
Caller - SEMS 1 - SEMS 2
-- INVITE w/o SDP -->
<-- 200 OK w SDP --
<-- Re-INVITE w SDP --
-- 200 OK w SDP -->
<-- ACK w/o SDP --
-- ACK w SDP -->
The attached patch contains another enhancement. Previously,
SEMS 1 forwarded the o-line of the SEMS 2 SDP unchanged, which
resulted in changing o-line session ids from the perspective of
the caller. Some UAs don't accept this. Therefore the AmB2B*Session
classes now cache the first o-line they ever send out and replace
the session is and user name in subsequent o-lines they send out with
the values from the saved o-line (also incrementing the session version
by one).
I would be glad if you could apply the attached patch, so that we don't
have to maintain it. If there's any problems with it, let me know.
Cheers,
Emil
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
--
Stefan Sayer
CEO (Geschäftsführer)
FRAFOS GmbH
email: [email protected]
mobile:+49 162 1366449
www.frafos.com
Prinzessinnenstr. 19/20 betahaus
10969 Berlin
Germany
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
