[OpenSIPS-Users] Prevent re-INVITE to T.38
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 Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Hi, Jeff. Maybe stream_exists(regexp) in sipmsgops module will be useful for you. Best regards, Alexander Mustafin mustafin.aleksa...@gmail.com 11 марта 2014 г., в 20:07, Jeff Pyle написал(а): > 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 > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users signature.asc Description: Message signed with OpenPGP using GPGMail ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
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 <
mustafin.aleksa...@gmail.com> wrote:
> Hi, Jeff.
>
> Maybe stream_exists(regexp) in sipmsgops module will be useful for you.
>
> Best regards,
> Alexander Mustafin
> mustafin.aleksa...@gmail.com
>
>
>
>
> 11 марта 2014 г., в 20:07, Jeff Pyle написал(а):
>
> 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
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Remove the codec and let the re-INVITE go through.
Regards,
Ovidiu Sas
On Tue, Mar 11, 2014 at 1:42 PM, 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 <
> mustafin.aleksa...@gmail.com> wrote:
>
>> Hi, Jeff.
>>
>> Maybe stream_exists(regexp) in sipmsgops module will be useful for you.
>>
>> Best regards,
>> Alexander Mustafin
>> mustafin.aleksa...@gmail.com
>>
>>
>>
>>
>> 11 марта 2014 г., в 20:07, Jeff Pyle
>> написал(а):
>>
>> 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
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
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 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 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 <
>> mustafin.aleksa...@gmail.com> wrote:
>>
>>> Hi, Jeff.
>>>
>>> Maybe stream_exists(regexp) in sipmsgops module will be useful for you.
>>>
>>> Best regards,
>>> Alexander Mustafin
>>> mustafin.aleksa...@gmail.com
>>>
>>>
>>>
>>>
>>> 11 марта 2014 г., в 20:07, Jeff Pyle
>>> написал(а):
>>>
>>> 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
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
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 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 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 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 <
>>> mustafin.aleksa...@gmail.com> wrote:
>>>
Hi, Jeff.
Maybe stream_exists(regexp) in sipmsgops module will be useful for you.
Best regards,
Alexander Mustafin
mustafin.aleksa...@gmail.com
11 марта 2014 г., в 20:07, Jeff Pyle
написал(а):
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
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
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 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 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 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 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 <
mustafin.aleksa...@gmail.com> wrote:
> Hi, Jeff.
>
> Maybe stream_exists(regexp) in sipmsgops module will be useful for you.
>
> Best regards,
> Alexander Mustafin
> mustafin.aleksa...@gmail.com
>
>
>
>
> 11 марта 2014 г., в 20:07, Jeff Pyle
> написал(а):
>
> 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
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Well, then your out of luck here.
Even if there's no SDP in ACK, should be fine.
On the other hand, if one end doesn't support T.38 and the other end
is insisting on it, the call will fail, so you can just drop the call
there.
-ovidiu
On Tue, Mar 11, 2014 at 3:14 PM, Jeff Pyle wrote:
> 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 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
>> 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
>>> 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
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
> wrote:
>>
>> Hi, Jeff.
>>
>> Maybe stream_exists(regexp) in sipmsgops module will be useful for
>> you.
>>
>> Best regards,
>> Alexander Mustafin
>> mustafin.aleksa...@gmail.com
>>
>>
>>
>>
>> 11 марта 2014 г., в 20:07, Jeff Pyle
>> написал(а):
>>
>> 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
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Our use case is a call forward from an inbound carrier gateway to an
outbound one. Both do support T.38. In fact, that's the problem. We've
seen much higher success rates with fax forwards if both sides stay G.711.
Quite interesting considering in many cases both the originating and
terminating gateways are Sonus GSX, although on different carrier networks.
And, before you ask, I'm not bringing the media through my network. :)
I'm not quite ready to test yet. When I am, I'll try the SDP stripping
approach and see how the gateways behave. Perhaps if I strip the SDP in
both the offer and the answer...
- Jeff
On Tue, Mar 11, 2014 at 3:29 PM, Ovidiu Sas wrote:
> Well, then your out of luck here.
> Even if there's no SDP in ACK, should be fine.
>
> On the other hand, if one end doesn't support T.38 and the other end
> is insisting on it, the call will fail, so you can just drop the call
> there.
>
> -ovidiu
>
> On Tue, Mar 11, 2014 at 3:14 PM, Jeff Pyle
> wrote:
> > 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
> 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
> >> 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
> >>> 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
> 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
> > wrote:
> >>
> >> Hi, Jeff.
> >>
> >> Maybe stream_exists(regexp) in sipmsgops module will be useful for
> >> you.
> >>
> >> Best regards,
> >> Alexander Mustafin
> >> mustafin.aleksa...@gmail.com
> >>
> >>
> >>
> >>
> >> 11 марта 2014 г., в 20:07, Jeff Pyle
> >> написал(а):
> >>
> >> 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
> >> Users@lists.opensips.org
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >>
> >>
> >> ___
> >> Users mailing list
> >> Users@lists.opensips.org
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> ___
> Users mailing list
> Users@lists.open
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
It must be the new fax machines that are using high speeds that are not
supported by T.38. Striping SDP completely may create issues ... IIRC you
are not allowed to have no SDP in INVITEs.
On Mar 12, 2014 8:48 AM, "Jeff Pyle" wrote:
> Our use case is a call forward from an inbound carrier gateway to an
> outbound one. Both do support T.38. In fact, that's the problem. We've
> seen much higher success rates with fax forwards if both sides stay G.711.
> Quite interesting considering in many cases both the originating and
> terminating gateways are Sonus GSX, although on different carrier networks.
>
> And, before you ask, I'm not bringing the media through my network. :)
>
> I'm not quite ready to test yet. When I am, I'll try the SDP stripping
> approach and see how the gateways behave. Perhaps if I strip the SDP in
> both the offer and the answer...
>
>
> - Jeff
>
>
>
> On Tue, Mar 11, 2014 at 3:29 PM, Ovidiu Sas wrote:
>
>> Well, then your out of luck here.
>> Even if there's no SDP in ACK, should be fine.
>>
>> On the other hand, if one end doesn't support T.38 and the other end
>> is insisting on it, the call will fail, so you can just drop the call
>> there.
>>
>> -ovidiu
>>
>> On Tue, Mar 11, 2014 at 3:14 PM, Jeff Pyle
>> wrote:
>> > 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
>> 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
>> >> 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
>> >>> 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
>> 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
>> > wrote:
>> >>
>> >> Hi, Jeff.
>> >>
>> >> Maybe stream_exists(regexp) in sipmsgops module will be useful for
>> >> you.
>> >>
>> >> Best regards,
>> >> Alexander Mustafin
>> >> mustafin.aleksa...@gmail.com
>> >>
>> >>
>> >>
>> >>
>> >> 11 марта 2014 г., в 20:07, Jeff Pyle
>> >> написал(а):
>> >>
>> >> 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
>> >> Users@lists.opensips.org
>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >>
>> >>
>> >>
>> >> ___
>> >> Users mailing list
>> >> Users@lists.opensips.org
>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
T.38 v2 supports up to 14.4k (V.17), v3 supports 33.6k (V.34). None of my carrier partners' gateways support T.38 v3. A SuperG3 capable fax machine supports up to 33.6k (V.34). Let's say we have two SG3 machines trying to talk to each other with an IP/T.38 v2 link in the middle. Since the gateways are reconstructing all the T.30 info, the term side spoofs the DIS to indicate a maximum supported speed of V.17 14.4k, so the originating side's DCS says, "Sure, 14.4 is it!" So, there shouldn't be any problem if two faster machines communicating at a max of 14.4k V.17 through a T.38 link. Speed isn't the issue. In fact, in some cases, it can be our friend. Read on... I think it's more a of a general compatibility issue. On our own network we've found G.711 with large, fixed jitter buffers is more likely to negotiate successfully than a T.38 call. The difference in success rate isn't huge but it's enough to cause us to use G.711 by default. If the call is up long enough to cause the modems' HDLC sync to slip because of jitter buffer under/overrun (or something like that), the call will blow up. On our network using a lot of Adtran TA-series gateways, that happens in no less than 45 minutes normall, sometimes as long as hours or more. And since on G.711 it seems to be a time related issue, we encourage our customers' machines to run at full 33.6k V.34 speeds. In other words, get as many pages through as possible before HDLC skew breaks the call. This is contrary to most advice you'll find to slow machines to V.29 9600. I find if the network is properly configured, V.34 33.6k is a stable reality. Anyway, back to the issue at hand. T.38 negotiations are rather heavy handed compared to letting G.711 through. So, even on carrier gateway to carrier gateway calls setups, we find G.711 more stable. That's why I'm looking for a way to 488 the re-invite from one side or the other to preserve the G.711 state. I suppose I could insert a Freeswitch instance in the middle to inspect the SDP, but that's ... not my first choice. Does that make sense? :) - Jeff On Wed, Mar 12, 2014 at 11:17 AM, Ovidiu Sas wrote: > It must be the new fax machines that are using high speeds that are not > supported by T.38. Striping SDP completely may create issues ... IIRC you > are not allowed to have no SDP in INVITEs. > On Mar 12, 2014 8:48 AM, "Jeff Pyle" wrote: > >> Our use case is a call forward from an inbound carrier gateway to an >> outbound one. Both do support T.38. In fact, that's the problem. We've >> seen much higher success rates with fax forwards if both sides stay G.711. >> Quite interesting considering in many cases both the originating and >> terminating gateways are Sonus GSX, although on different carrier networks. >> >> And, before you ask, I'm not bringing the media through my network. :) >> >> I'm not quite ready to test yet. When I am, I'll try the SDP stripping >> approach and see how the gateways behave. Perhaps if I strip the SDP in >> both the offer and the answer... >> >> >> - Jeff >> >> >> >> On Tue, Mar 11, 2014 at 3:29 PM, Ovidiu Sas wrote: >> >>> Well, then your out of luck here. >>> Even if there's no SDP in ACK, should be fine. >>> >>> On the other hand, if one end doesn't support T.38 and the other end >>> is insisting on it, the call will fail, so you can just drop the call >>> there. >>> >>> -ovidiu >>> >>> On Tue, Mar 11, 2014 at 3:14 PM, Jeff Pyle >>> wrote: >>> > 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 >>> 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 >>> >> 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 >>> >>> wrote: >>> >>> Remove the codec and
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
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
mailto:mustafin.aleksa...@gmail.com>>
wrote:
Hi, Jeff.
Maybe stream_exists(regexp) in sipmsgops module will be useful for
you.
Best regards,
Alexander Mustafin
mustafin.aleksa...@gmail.com
11 ? 2014 ?., ? 20:07, Jeff Pyle mailto:jp...@fidelityvoice.com>> ???(?):
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
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
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
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 Developerhttp://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 <
> mustafin.aleksa...@gmail.com> wrote:
>
>> Hi, Jeff.
>>
>> Maybe stream_exists(regexp) in sipmsgops module will be useful for you.
>>
>> Best regards,
>> Alexander Mustafin
>> mustafin.aleksa...@gmail.com
>>
>>
>>
>>
>> 11 марта 2014 г., в 20:07, Jeff Pyle
>> написал(а):
>>
>>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
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> ___
> Users mailing
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Hi Jeff,
Alice expects just a higher cseq number, not an increment with 1 or any
step...just higher than the prev one :)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 17.03.2014 17:52, Jeff Pyle 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
mailto:bog...@opensips.org>> 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
mailto:mustafin.aleksa...@gmail.com>> wrote:
Hi, Jeff.
Maybe stream_exists(regexp) in sipmsgops module will be
useful for you.
Best regards,
Alexander Mustafin
mustafin.aleksa...@gmail.com
11 марта 2014 г., в 20:07, Jeff Pyle mailto:jp...@fidelityvoice.com>> написал(а):
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
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Excellent! Apparently I mis-read this part of the RFC. Thanks.
- Jeff
On Mon, Mar 17, 2014 at 12:02 PM, Bogdan-Andrei Iancu
wrote:
> Hi Jeff,
>
> Alice expects just a higher cseq number, not an increment with 1 or any
> step...just higher than the prev one :)
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 17.03.2014 17:52, Jeff Pyle 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 > 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 Developerhttp://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 <
>> mustafin.aleksa...@gmail.com> wrote:
>>
>>> Hi, Jeff.
>>>
>>> Maybe stream_exists(regexp) in sipmsgops module will be useful for
>>> you.
>>>
>>> Best regards,
>>> Alexander Mustafin
>>> mustafin.aleksa...@gmail.com
>>>
>>>
>>>
>>>
>>> 11 марта 2014 г., в 20:07, Jeff Pyle
>>> написал(а):
>>>
>>>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
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>> ___
>> Users mailing
>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
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 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
> 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
>> wrote:
>>>
>>> Hi, Jeff.
>>>
>>> Maybe stream_exists(regexp) in sipmsgops module will be useful for you.
>>>
>>> Best regards,
>>> Alexander Mustafin
>>> mustafin.aleksa...@gmail.com
>>>
>>>
>>>
>>>
>>> 11 марта 2014 г., в 20:07, Jeff Pyle
>>> написал(а):
>>>
>>> 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
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Beautiful.
- Jeff
On Mon, Mar 17, 2014 at 12:30 PM, Ovidiu Sas wrote:
> 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
> 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 <
> bog...@opensips.org>
> > 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
> >> wrote:
> >>>
> >>> Hi, Jeff.
> >>>
> >>> Maybe stream_exists(regexp) in sipmsgops module will be useful for you.
> >>>
> >>> Best regards,
> >>> Alexander Mustafin
> >>> mustafin.aleksa...@gmail.com
> >>>
> >>>
> >>>
> >>>
> >>> 11 марта 2014 г., в 20:07, Jeff Pyle
> >>> написал(а):
> >>>
> >>> 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
> >>> Users@lists.opensips.org
> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>>
> >>>
> >>>
> >>> ___
> >>> Users mailing list
> >>> Users@lists.opensips.org
> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>>
> >>
> >>
> >>
> >> ___
> >> Users mailing list
> >> Users@lists.opensips.org
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >>
> >
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
