Hi Stefan, I saw, that you committed something, to aleviate this problem ( in commit b03a3903f9754ca382d2ac83d9b2666ea9850705).But will that be the final solution to the problem?
As I understand it the getSdpOffer()/getSdpAnswer() functions are meant to be overwritten in SEMS application code and the application code might want to get informed about the previous SDP. So your solution to pass the previous SDP to the application code might be viable. However, wouldn't it be desirable to have a sane default SDP handling, such that common problems like the handling of the session version in the originator line does not have to be implemented by each application on its own? I think, yes. Therefor, I would like to propose to change the interface of getSdpOffer()/getSdpAnswer() to contain a pointer to the previous SDP which is NULL in the initial INVITE transaction. For the SDP generated by getSdpOffer()/getSdpAnswer() then the offer respectively answer pass-by-reference parameters can be used, but they can be pre-initialized to an empty state containing only the session identifier and session version in the originator line. When the getSdpOffer()/getSdpAnswer() returns the logic I implemented in the patch attached to the original message in this thread can be used to determine, if the session version in the originator line should be incremented by one. With respect to the onSdpCompleted() callback in the AmSession interface, I think that the current behaviour of calling RTPAudio::init() for each Re-INVITE does not work. In my tests, the audio was lost after calling RTPAudio::init() a second time and I suspect, that this is due to RTPAudio::init() calling resume(). What do you think? Regards, Emil Start weitergeleitete Nachricht: Datum: Thu, 23 Jun 2011 12:23:45 +0200 Von: Emil Kroymann <[email protected]> An: [email protected] Betreff: [Semsdev] Handling of Re-INVITEs and version in o= line Hi, I noticed, that SEMS master currently does not support Re-INVITEs which contain an SDP offer. The problem is, that the old local SDP is given to getSdpAnswer and this routine then adds another m= line which is, however, invalid. I tried to correctly implement the Re-INVITE functionality in the attached diff. The implementation works as follows: - the old local sdp is copied to a backup - the local_sdp instance variable is cleared - the getSdpAnswer method is called with the cleared instance variable - the old local sdp and the new local sdp are compared; if they differ the version in the o= line of the new sdp is incremented by on as the offer-answer rfc mandates I also fixed a minor problem, where the session id and session version in the o= line were always set to 0 (or 1, don't remember). As for the media handling in case of Re-INVITE, I adapted the onSdpCompleted method of AmSession, to not call RtpStream::init again, if the session is already attached to the media processor thread. In this case only the "sendonly" attribute of the remote SDP is evaluated and if it is present, the setOnHold(true) method of the RTPStream() object is called. Probably there are more ways in which an RTPStream can be modified, but only the "set on hold" functionality is implemented. Also, the case of Re-INVITEs without SDP is probably not handled yet. Regards, Emil -- 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 -- 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
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
