Hi, Am Fri, 24 Feb 2012 21:30:17 +0100 schrieb Stefan Sayer <[email protected]>:
> 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. This call flow is only available if the call was established by an incoming initial INVITE. Not if the call was established by an initial INVITE generated by SEMS 1. In our case - both for dial in and dial out, it is not appropriate, because we first handle media with SEMS 1 and only later with SEMS 2, and then want the correct media setup without having to re-invite SEMS 2 immediately after the initial INVITE transaction. Could we make the call flow, I implemented, optionally available? Maybe it is sufficient to only use this call flow, if the initial INVITE to SEMS 2 is sent after the initial INVITE transaction has already finished (or should it be "more" optional?), because I think in this case it's not correct to send the offer from the caller which has already been answered as offer to SEMS 2. > > 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? I will split this functionality out, but I think it is placed pretty generically everywhere where also the replaceConnectionAddress function for rtp relay mode would be called. I'll send the split-up patches. Regards, Emil > > 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 > > -- Emil Kroymann VoIP Services Engineer Email: [email protected] Tel: +49-30-203899885 Mobile: +49-176-38389303 ISACO GmbH Kurfürstenstraße 79 10787 Berlin Germany Amtsgericht Charlottenburg, HRB 112464B Geschäftsführer: Daniel Frommherz
signature.asc
Description: PGP signature
_______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
