16 Jul
2024
16 Jul
'24
9:54 a.m.
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
16 Jul
16 Jul
12:59 p.m.
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(a)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(a)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
1:08 p.m.
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(a)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
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On Jul 16, 2024, at 3:54 AM, Tim Bowyer via
sr-users <sr-users(a)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(a)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
1:54 p.m.
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:08 schrieb Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)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(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
2:26 p.m.
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:08 schrieb Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
2:56 p.m.
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:08 schrieb Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
3:23 p.m.
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 14:56 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:08 schrieb Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
3:37 p.m.
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 15:23 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 14:56 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:08 schrieb Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
1:54 p.m.
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 12:59 schrieb Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
2:26 p.m.
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 12:59 schrieb Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)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(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
2:56 p.m.
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 12:59 schrieb Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
3:23 p.m.
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 14:56 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 12:59 schrieb Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
3:37 p.m.
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 15:23 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 14:56 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 14:26 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 13:54 schrieb Oliver Roth via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)nexphone.ch
Freundliche Grüsse
Oli Roth
Am 16.07.2024 um 12:59 schrieb Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org>rg>:
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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
94
days inactive
94
days old
12 comments
3 participants
participants (3)
-
Alex Balashov -
Oliver Roth -
Tim Bowyer