Hello Everyone,
I've been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
1. Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. 2. INVITE sent to Asterisk with the same SDP, payload = 96 3. INVITE sent from Asterisk to Client with payload = 101 * 200 OK w/SDP from Client has payload = 101 * 200 OK w/SDP to Kamailio has payload = 96 * 200 OK w/SDP to Carrier has payload = 96 4. Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client 5. Kamailio passes this onto Carrier with media IP of RTPengine 6. 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio 7. Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn't do anything further
+---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+
Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
* Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). * The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). * There's nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting.
Any ideas?
Cheers,
Tim Bowyer
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further+---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting.Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Tim,
I followed up with someone in a better position to know and they confirm that my response to you was correct -- this is a problem area for Asterisk at present.
-- Alex
On Jul 16, 2024, at 6:59 AM, Alex Balashov abalashov@evaristesys.com wrote:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:08 schrieb Alex Balashov via sr-users sr-users@lists.kamailio.org:
Tim,
I followed up with someone in a better position to know and they confirm that my response to you was correct -- this is a problem area for Asterisk at present.
-- Alex
On Jul 16, 2024, at 6:59 AM, Alex Balashov abalashov@evaristesys.com wrote:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:08 schrieb Alex Balashov via sr-users sr-users@lists.kamailio.org:
Tim,
I followed up with someone in a better position to know and they confirm that my response to you was correct -- this is a problem area for Asterisk at present.
-- Alex
On Jul 16, 2024, at 6:59 AM, Alex Balashov abalashov@evaristesys.com wrote:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:08 schrieb Alex Balashov via sr-users sr-users@lists.kamailio.org:
Tim,
I followed up with someone in a better position to know and they confirm that my response to you was correct -- this is a problem area for Asterisk at present.
-- Alex
On Jul 16, 2024, at 6:59 AM, Alex Balashov abalashov@evaristesys.com wrote:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 14:56 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:08 schrieb Alex Balashov via sr-users sr-users@lists.kamailio.org:
Tim,
I followed up with someone in a better position to know and they confirm that my response to you was correct -- this is a problem area for Asterisk at present.
-- Alex
On Jul 16, 2024, at 6:59 AM, Alex Balashov abalashov@evaristesys.com wrote:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 15:23 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 14:56 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:08 schrieb Alex Balashov via sr-users sr-users@lists.kamailio.org:
Tim,
I followed up with someone in a better position to know and they confirm that my response to you was correct -- this is a problem area for Asterisk at present.
-- Alex
On Jul 16, 2024, at 6:59 AM, Alex Balashov abalashov@evaristesys.com wrote:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 12:59 schrieb Alex Balashov via sr-users sr-users@lists.kamailio.org:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 12:59 schrieb Alex Balashov via sr-users sr-users@lists.kamailio.org:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 12:59 schrieb Alex Balashov via sr-users sr-users@lists.kamailio.org:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 14:56 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 12:59 schrieb Alex Balashov via sr-users sr-users@lists.kamailio.org:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 15:23 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 14:56 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users sr-users@lists.kamailio.org:
Guten Tag
Ich bin bis am 4.8.24 abwesend. Die Nachrichten werden in diese Zeit nur sporadisch gelesen. E-Mails werden ab und zu gelesen und nicht weitergeleitet.
Für dringende Angelegenheiten wenden Sie sich bitte an: support@nexphone.ch
Freundliche Grüsse Oli Roth
Am 16.07.2024 um 12:59 schrieb Alex Balashov via sr-users sr-users@lists.kamailio.org:
Hi Tim,
All aspects of SDP negotiation are between Asterisk and the Client, on that last call leg (the "B"-leg). Asterisk states to the client how it will handle DTMF and chooses a payload type (SDP offer), and the client responds to Asterisk in kind (SDP answer). If any adaptation is required between the "B" and "A"-leg, that is up to Asterisk to perform, so it must stay in the path.
What you seem to desire is a fully transparent B2BUA mode from Asterisk where it has no stake in the media parameters whatsoever, and simply passes it along what it receives from the counterparties on both the "A" and "B" legs. As far as I know, this does not exist.
-- Alex
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via sr-users sr-users@lists.kamailio.org wrote:
Hello Everyone, I’ve been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece.
• Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. • INVITE sent to Asterisk with the same SDP, payload = 96 • INVITE sent from Asterisk to Client with payload = 101 • 200 OK w/SDP from Client has payload = 101 • 200 OK w/SDP to Kamailio has payload = 96 • 200 OK w/SDP to Carrier has payload = 96 • Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client • Kamailio passes this onto Carrier with media IP of RTPengine • 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio • Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn’t do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier.
• Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). • The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). • There’s nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Alex Balashov -
Oliver Roth -
Tim Bowyer