Hello all,
I've been hitting a wall in getting T.38 fallback to G.711 to work in a specific case, and I was wondering if I could use kamailio to the rescue, since all my other endeavours have failed miserably.
In short, this is this the scenario where I need to have this manipulation happen: - During an established dialog between a SIP endpoint and asterisk (with kamailio in the middle acting as proxy), the latter (asterisk) sends a re-INVITE with a single offer for m=image with T.38 in the SDP. - The other (eccentric) endpoint (yes, it's a Cisco) replies with 200 OK, but will reject the T.38 offer in the SDP body instead by including a port number of '0' - Instead of falling back to G.711 as configured, asterisk in that case will do nothing, and the dialog will eventually end with a BYE (don't remember which of the two endpoints will send that, but it doesn't matter much)
The thing here is that asterisk *WILL* fallback to G711 with a second re-INVITE, if the other endpoint replies to the first T.38 re-INVITE with a negative response (488) instead of a positive one (200) declining the media in the SDP body. I've looked at using freeswitch for a fax gateway instead, but apparently FS doesn't support fallback at all even in the 488 reply case, much less in the inactive media stream in 200 OK corner case I'm investigating.
So, I thought I'd do that in kamailio and convert those 200 OKs to 488s with change_reply_status() from the textopsx module. Of course, the universe hates me, and this will fail spectacularly:
ERROR: textopsx [textopsx.c:301]: ki_change_reply_status(): the class of
provisional or positive final replies cannot be changed
So you can't change a reply's "class" with change_reply_status(), only the response code within that class can be manipulated.
I guess my question is now whether there is any way to do this sort of transformation with kamailio, perhaps with some other function or method?
If anyone else has had to deal with this problem and come up with a different solution I'd be glad to hear it, as neither my head nor the surrounding walls can take any more mutual banging at this point. Thanks!
BR, George.
P.S. I hate fax
I think this is the wrong job for Kamailio.
On Mon, May 21, 2018 at 10:16:20PM +0300, George Diamantopoulos wrote:
Hello all,
I've been hitting a wall in getting T.38 fallback to G.711 to work in a specific case, and I was wondering if I could use kamailio to the rescue, since all my other endeavours have failed miserably.
In short, this is this the scenario where I need to have this manipulation happen:
- During an established dialog between a SIP endpoint and asterisk (with
kamailio in the middle acting as proxy), the latter (asterisk) sends a re-INVITE with a single offer for m=image with T.38 in the SDP.
- The other (eccentric) endpoint (yes, it's a Cisco) replies with 200 OK,
but will reject the T.38 offer in the SDP body instead by including a port number of '0'
- Instead of falling back to G.711 as configured, asterisk in that case
will do nothing, and the dialog will eventually end with a BYE (don't remember which of the two endpoints will send that, but it doesn't matter much)
The thing here is that asterisk *WILL* fallback to G711 with a second re-INVITE, if the other endpoint replies to the first T.38 re-INVITE with a negative response (488) instead of a positive one (200) declining the media in the SDP body. I've looked at using freeswitch for a fax gateway instead, but apparently FS doesn't support fallback at all even in the 488 reply case, much less in the inactive media stream in 200 OK corner case I'm investigating.
So, I thought I'd do that in kamailio and convert those 200 OKs to 488s with change_reply_status() from the textopsx module. Of course, the universe hates me, and this will fail spectacularly:
ERROR: textopsx [textopsx.c:301]: ki_change_reply_status(): the class of
provisional or positive final replies cannot be changed
So you can't change a reply's "class" with change_reply_status(), only the response code within that class can be manipulated.
I guess my question is now whether there is any way to do this sort of transformation with kamailio, perhaps with some other function or method?
If anyone else has had to deal with this problem and come up with a different solution I'd be glad to hear it, as neither my head nor the surrounding walls can take any more mutual banging at this point. Thanks!
BR, George.
P.S. I hate fax
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
I know, but I'm that desperate.
On 21 May 2018 at 22:17, Alex Balashov abalashov@evaristesys.com wrote:
I think this is the wrong job for Kamailio.
On Mon, May 21, 2018 at 10:16:20PM +0300, George Diamantopoulos wrote:
Hello all,
I've been hitting a wall in getting T.38 fallback to G.711 to work in a specific case, and I was wondering if I could use kamailio to the rescue, since all my other endeavours have failed miserably.
In short, this is this the scenario where I need to have this
manipulation
happen:
- During an established dialog between a SIP endpoint and asterisk (with
kamailio in the middle acting as proxy), the latter (asterisk) sends a re-INVITE with a single offer for m=image with T.38 in the SDP.
- The other (eccentric) endpoint (yes, it's a Cisco) replies with 200 OK,
but will reject the T.38 offer in the SDP body instead by including a
port
number of '0'
- Instead of falling back to G.711 as configured, asterisk in that case
will do nothing, and the dialog will eventually end with a BYE (don't remember which of the two endpoints will send that, but it doesn't matter much)
The thing here is that asterisk *WILL* fallback to G711 with a second re-INVITE, if the other endpoint replies to the first T.38 re-INVITE
with a
negative response (488) instead of a positive one (200) declining the
media
in the SDP body. I've looked at using freeswitch for a fax gateway
instead,
but apparently FS doesn't support fallback at all even in the 488 reply case, much less in the inactive media stream in 200 OK corner case I'm investigating.
So, I thought I'd do that in kamailio and convert those 200 OKs to 488s with change_reply_status() from the textopsx module. Of course, the universe hates me, and this will fail spectacularly:
ERROR: textopsx [textopsx.c:301]: ki_change_reply_status(): the class
of
provisional or positive final replies cannot be changed
So you can't change a reply's "class" with change_reply_status(), only
the
response code within that class can be manipulated.
I guess my question is now whether there is any way to do this sort of transformation with kamailio, perhaps with some other function or method?
If anyone else has had to deal with this problem and come up with a different solution I'd be glad to hear it, as neither my head nor the surrounding walls can take any more mutual banging at this point. Thanks!
BR, George.
P.S. I hate fax
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Mon, May 21, 2018 at 10:28:06PM +0300, George Diamantopoulos wrote:
I know, but I'm that desperate.
Sometimes you just have to solve the problem differently. Can't put the milk back into the cow.
Theoretically speaking though, and notwithstanding any FDA restrictions on this, would it be possible to collect the cow's milk, process all lactose out with event_route[network:msg] and then distribute to undiagnosed intolerant consumers?
I guess no one will encourage me to go through with that, but should I decide nonetheless to give it a go it would save me some trouble if I knew it can't be done beforehand...
On 21 May 2018 at 22:29, Alex Balashov abalashov@evaristesys.com wrote:
On Mon, May 21, 2018 at 10:28:06PM +0300, George Diamantopoulos wrote:
I know, but I'm that desperate.
Sometimes you just have to solve the problem differently. Can't put the milk back into the cow.
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users