Hello, o Peter Lemenkov [08/20/08 14:45]: >> Now that there is the sipctrl stack and with binrpcctrl a more powerful >> X/ser module, its possible to implement that, bit both stacks would first >> have to give the upper layer the possibility to get/send ACK. > > Actually I need music-on-hold server, which somewhat different than > one described at draft-ietf-sipping-service-examples-08.txt . I need > to make the following strange trick. > > * A calls B > * A puts B on hold > > I want to substitute RTP media from A by one from SEMS. For example: > > * A calls B > * A tries to put B on hold by sending INVITE to OpenSER > * OpenSER catches this invite and sends it to the SEMS > * SEMS modifies INVITE and sends it back to OpenSER > * OpenSER sends invite to B > * B sends 200OK to OpenSER > * OpenSER sends 200OK to SEMS > * SEMS sends ACK back to OpenSER (which sends it to B) and starts to > stream my RTP > * etc
I am not sure this is a clever thing to do. You are breaking into the established dialog afterwards, and messing with the sdp...in the normal case, if there are no errors, it will probably work, but what about if there are retransmissions, another reinvite from the B party, possibly also on hold, etc. This is much cleaner done with 3pcc, or b2bua from the start of the dialog (but i understand you probably don't want to have all your calls going through b2b). in sems you have all the pieces in place, but you will need to combine them a clever way to achieve this. you will need to teach sems to take existing dialog identifiers from the INVITE, and then combine the original SDP (take originator line from it in case your phone looks at that) with sems-generated one, probably using getCompatiblePayload function. The sdp from 200 would go to sems again, to be eaten by acceptAudio, and then the question is what to send to A, probably a newly generated SDP with on hold so that A does not expect media (which would give an RTP timeout). I think there are plenty of ways this can get messed up - but, as always, if you know the UAs you do this with, or e.g. if it is some known gateways on one side, then it might work quite well. Stefan > > -- Stefan Sayer VoIP Services [EMAIL PROTECTED] www.iptego.com iptego GmbH Am Borsigturm 40 13507 Berlin Germany Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
