Track the call with the dialog module in top hiding mode. It will handle CSeq changes. Sorry, I want it to send this a while ago but I got distracted.
-ovidiu On Mon, Mar 17, 2014 at 11:52 AM, Jeff Pyle <[email protected]> wrote: > Hi Bogdan, > > Let's say Bob reinvites Alice to T.38 through my proxy. My proxy declines > the reinvite. That transaction has completed and Bob has incremented his > CSeq number. Now, if Bob sends another in-dialog request (such as a BYE), > the CSeq is one higher than Alice is expecting. That's not a problem? > Alice won't reply with a 400? > > > - Jeff > > > > On Mon, Mar 17, 2014 at 11:24 AM, Bogdan-Andrei Iancu <[email protected]> > wrote: >> >> Hi Jeff, >> >> This is a false problem - you can simply decline the re-INVITE without >> breaking anything - each side has its own cseq number, and they are >> independently increased when a party is generating a new requests. >> >> So, just decline it and that's it ! >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 11.03.2014 19:42, Jeff Pyle wrote: >> >> Hi Alexander, >> >> To detect the "image" session in the SDP, you are thinking the same way >> that I am. The problem I see is how to actually reject the re-INVITE. If I >> were to do something like a sl_send_reply("488", "Not Acceptable Here"), >> that would work in the moment, but the CSeq values would be increased by one >> on side compared to the other. That sounds to me like a recipe for problems >> in future in-dialog transactions (like BYE). >> >> >> >> - Jeff >> >> >> >> >> On Tue, Mar 11, 2014 at 12:58 PM, Alexander Mustafin >> <[email protected]> wrote: >>> >>> Hi, Jeff. >>> >>> Maybe stream_exists(regexp) in sipmsgops module will be useful for you. >>> >>> Best regards, >>> Alexander Mustafin >>> [email protected] >>> >>> >>> >>> >>> 11 марта 2014 г., в 20:07, Jeff Pyle <[email protected]> >>> написал(а): >>> >>> Hello, >>> >>> Is there anything I can do at the proxy level to prevent a dialog from >>> reinviting to to T.38? I think I could detect the T.38 attributes easily >>> enough and respond with a 488, although I'm concerned the CSeq values would >>> be out of sequence for the next transaction that did make it through the >>> proxy to the far end. That could cause a problem, no? >>> >>> Is this something that requires a B2BUA? Is it possible from within the >>> OpenSIPS B2B modules to do SDP inspection of any sort? >>> >>> >>> - Jeff >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- VoIP Embedded, Inc. http://www.voipembedded.com _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
