Hi All,
Trying to work out a way to detect and re-route inbound calls which negotiate or contain t.38 SDP to answer/process faxes efficiently. Plan is to put Kamailio in front of a quantity of FreeSwitch servers - most virtual, others physical. Virtual servers will handle inbound faxes which negotiate t.38, and physical servers will answer ulaw/alaw faxes with mod_spandsp.
The bulk of inbound faxes negotiate t.38, but in order to scale our inbound system we need some way to work out which way to send the calls prior to the dispatcher.
Many thanks for your help in advance,
Tim
Hello,
to be sure I understand correctly, do you want to re-route a call to another freeswitch when re-INVITE has t.38, even the initial INVITE was sent to a different freeswitch?
Cheers, Daniel
On 22.06.17 08:08, Tim Bowyer wrote:
Hi All,
Trying to work out a way to detect and re-route inbound calls which negotiate or contain t.38 SDP to answer/process faxes efficiently.
Plan is to put Kamailio in front of a quantity of FreeSwitch servers – most virtual, others physical.
Virtual servers will handle inbound faxes which negotiate t.38, and physical servers will answer ulaw/alaw faxes with mod_spandsp.
The bulk of inbound faxes negotiate t.38, but in order to scale our inbound system we need some way to work out which way to send the calls prior to the dispatcher.
Many thanks for your help in advance,
Tim
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel,
Thanks for the prompt reply! Correct - this may not even be possible? (I've read this strange task may be possible leveraging the b2bua module in OpenSIPS but I don't want to go down that path!!)
Cheers,
Tim
Subject: Re: [SR-Users] Help detecting t.38 and routing accordingly
Hello, to be sure I understand correctly, do you want to re-route a call to another freeswitch when re-INVITE has t.38, even the initial INVITE was sent to a different freeswitch?
Cheers, Daniel On 22.06.17 08:08, Tim Bowyer wrote: Hi All,
Trying to work out a way to detect and re-route inbound calls which negotiate or contain t.38 SDP to answer/process faxes efficiently. Plan is to put Kamailio in front of a quantity of FreeSwitch servers - most virtual, others physical. Virtual servers will handle inbound faxes which negotiate t.38, and physical servers will answer ulaw/alaw faxes with mod_spandsp.
The bulk of inbound faxes negotiate t.38, but in order to scale our inbound system we need some way to work out which way to send the calls prior to the dispatcher.
Many thanks for your help in advance,
Tim
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.comhttp://www.asipto.com
Kamailio World Conference - www.kamailioworld.comhttp://www.kamailioworld.com
Hello,
Kamailio can send a request anywhere you decide, the problem here is the FreeSwitch -- it will reject the re-INVITE if it didn't receive the initial INVITE.
The clean way here will be to transfer the call, so the first freeswitch will transfer it to the one you want after re-INVITE. You can add the new destination from Kamailio as an extra header on re-INVITE. Alternative is to bridge from first freeswitch to the second one, eventually with bypass media after re-invite.
A common use case is to differentiate between voice and fax tel numbers, then you can route from the initial invite based on the DID. Or have the freeswitch configured to handle both voice and fax calls.
Cheers, Daniel
On 22.06.17 09:22, Tim Bowyer wrote:
Hi Daniel,
Thanks for the prompt reply!
Correct – this may not even be possible? (I’ve read this strange task may be possible leveraging the b2bua module in OpenSIPS but I don’t want to go down that path!!)
Cheers,
Tim
*Subject:* Re: [SR-Users] Help detecting t.38 and routing accordingly
Hello,
to be sure I understand correctly, do you want to re-route a call to another freeswitch when re-INVITE has t.38, even the initial INVITE was sent to a different freeswitch?
Cheers, Daniel
On 22.06.17 08:08, Tim Bowyer wrote:
Hi All, Trying to work out a way to detect and re-route inbound calls which negotiate or contain t.38 SDP to answer/process faxes efficiently. Plan is to put Kamailio in front of a quantity of FreeSwitch servers – most virtual, others physical. Virtual servers will handle inbound faxes which negotiate t.38, and physical servers will answer ulaw/alaw faxes with mod_spandsp. The bulk of inbound faxes negotiate t.38, but in order to scale our inbound system we need some way to work out which way to send the calls prior to the dispatcher. Many thanks for your help in advance, Tim _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users-- Daniel-Constantin Mierla www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com http://www.asipto.com Kamailio World Conference - www.kamailioworld.com http://www.kamailioworld.com
Hello, in voip , it is hard to handle Fax issue. as Daniel said , i seperate/route to another SIP based server, Fax and Voice tel numbers with domain or DID number. in my network it is Asterisk and uses fax_spandsp.
Good luck.
-- View this message in context: http://sip-router.1086192.n5.nabble.com/Help-detecting-t-38-and-routing-acco... Sent from the Users mailing list archive at Nabble.com.
-
Daniel-Constantin Mierla -
Tim Bowyer -
ycaner