I'm trying to configure Kamailio to permit communication between devices:
some use TLS and SRTP
some UDP and RTP
with RTPEngine in the middle.
A priori I don't know if the device support SRTP or RTP so in the routing I have to detect on the fly how to act. The problem is this:
Call from RTP to SRTP device: 488 Not Acceptable here
Call from SRTP to RTP device: 415 Unsupported Media Type
Any hint?
Thank you
Regards
Does an examination of the SDP offer and answer respectively not divine the issue?
On Jan 27, 2022, at 5:35 PM, Social Boh social@bohboh.info wrote:
I'm trying to configure Kamailio to permit communication between devices:
some use TLS and SRTP
some UDP and RTP
with RTPEngine in the middle.
A priori I don't know if the device support SRTP or RTP so in the routing I have to detect on the fly how to act. The problem is this:
Call from RTP to SRTP device: 488 Not Acceptable here
Call from SRTP to RTP device: 415 Unsupported Media Type
Any hint?
Thank you
Regards
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
I can examine the request but how examine the answer if is a Error? Using a failure route?
Regards
--- I'm SoCIaL, MayBe
El 27/01/2022 a las 5:39 p. m., Alex Balashov escribió:
Does an examination of the SDP offer and answer respectively not divine the issue?
On Jan 27, 2022, at 5:35 PM, Social Boh social@bohboh.info wrote:
I'm trying to configure Kamailio to permit communication between devices:
some use TLS and SRTP
some UDP and RTP
with RTPEngine in the middle.
A priori I don't know if the device support SRTP or RTP so in the routing I have to detect on the fly how to act. The problem is this:
Call from RTP to SRTP device: 488 Not Acceptable here
Call from SRTP to RTP device: 415 Unsupported Media Type
Any hint?
Thank you
Regards
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hi,
Unfortunately in my experience "Opportunistic SRTP" support is broken in many UAs. There are (at least) two ways of doing it covered indirectly in RFC3264 https://tools.ietf.org/html/rfc3264 and the second explicitly in RFC8643 https://www.rfc-editor.org/rfc/rfc8643.html and devices seem to handle them differently. I've seen end devices that *can *support SRTP choose to use standard RTP when offered the wrong type of SDP body.
One thing I considered (but haven't tested so far) is using a late offer to discover what format the end device expects before sending an offer, but that might cause interop problems of its own.
Cheers
On Thu, Jan 27, 2022 at 10:54 PM Social Boh social@bohboh.info wrote:
I can examine the request but how examine the answer if is a Error? Using a failure route?
Regards
I'm SoCIaL, MayBe
El 27/01/2022 a las 5:39 p. m., Alex Balashov escribió:
Does an examination of the SDP offer and answer respectively not divine
the issue?
On Jan 27, 2022, at 5:35 PM, Social Boh social@bohboh.info wrote:
I'm trying to configure Kamailio to permit communication between
devices:
some use TLS and SRTP
some UDP and RTP
with RTPEngine in the middle.
A priori I don't know if the device support SRTP or RTP so in the
routing I have to detect on the fly how to act. The problem is this:
Call from RTP to SRTP device: 488 Not Acceptable here
Call from SRTP to RTP device: 415 Unsupported Media Type
Any hint?
Thank you
Regards
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@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
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
You would achieve this in a failure route, detecting the 488|415 negative replies then resuming the branch with a different SDP profile.
However, as others have said already, not all UAs will accept this "hack". Some will consider the new branch with a CSeq NOT incrementing as retransmission - and reject it with something like "482 Merged Request".
https://tools.ietf.org/html/rfc3261#section-8.2.2.2
8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction.
Regards, --Sergiu
On Thu, Jan 27, 2022 at 6:26 PM Marrold kamailio@marrold.co.uk wrote:
Hi,
Unfortunately in my experience "Opportunistic SRTP" support is broken in many UAs. There are (at least) two ways of doing it covered indirectly in RFC3264 https://tools.ietf.org/html/rfc3264 and the second explicitly in RFC8643 https://www.rfc-editor.org/rfc/rfc8643.html and devices seem to handle them differently. I've seen end devices that *can *support SRTP choose to use standard RTP when offered the wrong type of SDP body.
One thing I considered (but haven't tested so far) is using a late offer to discover what format the end device expects before sending an offer, but that might cause interop problems of its own.
Cheers
On Thu, Jan 27, 2022 at 10:54 PM Social Boh social@bohboh.info wrote:
I can examine the request but how examine the answer if is a Error? Using a failure route?
Regards
I'm SoCIaL, MayBe
El 27/01/2022 a las 5:39 p. m., Alex Balashov escribió:
Does an examination of the SDP offer and answer respectively not divine
the issue?
On Jan 27, 2022, at 5:35 PM, Social Boh social@bohboh.info wrote:
I'm trying to configure Kamailio to permit communication between
devices:
some use TLS and SRTP
some UDP and RTP
with RTPEngine in the middle.
A priori I don't know if the device support SRTP or RTP so in the
routing I have to detect on the fly how to act. The problem is this:
Call from RTP to SRTP device: 488 Not Acceptable here
Call from SRTP to RTP device: 415 Unsupported Media Type
Any hint?
Thank you
Regards
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@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
- sr-users@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
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Thank you to all for the tips...
Regards
--- I'm SoCIaL, MayBe
El 27/01/2022 a las 6:39 p. m., Sergiu Pojoga escribió:
You would achieve this in a failure route, detecting the 488|415 negative replies then resuming the branch with a different SDP profile.
However, as others have said already, not all UAs will accept this "hack". Some will consider the new branch with a CSeq NOT incrementing as retransmission - and reject it with something like "482 Merged Request".
https://tools.ietf.org/html/rfc3261#section-8.2.2.2
8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction.
Regards, --Sergiu
On Thu, Jan 27, 2022 at 6:26 PM Marrold kamailio@marrold.co.uk wrote:
Hi, Unfortunately in my experience "Opportunistic SRTP" support is broken in many UAs. There are (at least) two ways of doing it covered indirectly in RFC3264 <https://tools.ietf.org/html/rfc3264> and the second explicitly in RFC8643 <https://www.rfc-editor.org/rfc/rfc8643.html> and devices seem to handle them differently. I've seen end devices that /can /support SRTP choose to use standard RTP when offered the wrong type of SDP body. One thing I considered (but haven't tested so far) is using a late offer to discover what format the end device expects before sending an offer, but that might cause interop problems of its own. Cheers On Thu, Jan 27, 2022 at 10:54 PM Social Boh <social@bohboh.info> wrote: I can examine the request but how examine the answer if is a Error? Using a failure route? Regards --- I'm SoCIaL, MayBe El 27/01/2022 a las 5:39 p. m., Alex Balashov escribió: > Does an examination of the SDP offer and answer respectively not divine the issue? > >> On Jan 27, 2022, at 5:35 PM, Social Boh <social@bohboh.info> wrote: >> >> I'm trying to configure Kamailio to permit communication between devices: >> >> some use TLS and SRTP >> >> some UDP and RTP >> >> with RTPEngine in the middle. >> >> A priori I don't know if the device support SRTP or RTP so in the routing I have to detect on the fly how to act. The problem is this: >> >> Call from RTP to SRTP device: 488 Not Acceptable here >> >> Call from SRTP to RTP device: 415 Unsupported Media Type >> >> Any hint? >> >> Thank you >> >> Regards >> >> -- >> --- >> I'm SoCIaL, MayBe >> >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> * sr-users@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to the sender! >> Edit mailing list options or unsubscribe: >> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
Marrold -
Sergiu Pojoga -
Social Boh