By removing the SDP, am I not causing a late-offer behavior? The B-leg would expect an SDP on the ACK from the A-leg (which it's not going to get), and the A-leg is going to wonder why its T.38 SDP was answered with, say, a G.711 one.
I've yelled at customers for pulling stuff like that. :) - Jeff On Tue, Mar 11, 2014 at 2:00 PM, Ovidiu Sas <[email protected]> wrote: > Then remove completely the SDP. > The other endpoint should offer the previous codec. > The renegotiation should fail and hopefully the call will still stay on ... > > Regards, > Ovidiu Sas > > > On Tue, Mar 11, 2014 at 1:56 PM, Jeff Pyle <[email protected]>wrote: > >> Hi Ovidiu, >> >> In the case of a pure T.38 SDP offer like this: >> >> v=0 >> o=- 1394560461 1394560461 IN IP4 192.168.58.4 >> s=- >> c=IN IP4 192.168.58.4 >> t=0 0 >> m=image 16426 udptl t38 >> a=T38FaxVersion:0 >> a=T38FaxRateManagement:transferredTCF >> a=T38FaxFillBitRemoval:0 >> a=T38FaxTranscodingMMR:0 >> a=T38FaxTranscodingJBIG:0 >> a=T38MaxBitRate:14400 >> a=T38FaxUdpEC:t38UDPRedundancy >> a=T38FaxMaxBuffer:600 >> a=T38FaxMaxDatagram:200 >> >> >> Which codec would I remove? >> >> >> - Jeff >> >> >> >> On Tue, Mar 11, 2014 at 1:44 PM, Ovidiu Sas <[email protected]>wrote: >> >>> Remove the codec and let the re-INVITE go through. >>> >>> Regards, >>> Ovidiu Sas >>> >>> >>> >>> On Tue, Mar 11, 2014 at 1:42 PM, Jeff Pyle <[email protected]>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 >>>> >>>> >>> >>> >>> -- >>> VoIP Embedded, Inc. >>> http://www.voipembedded.com >>> >>> _______________________________________________ >>> 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 > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
