15 Oct
2024
15 Oct
'24
10:41 a.m.
Hi Gang
Parallel forking situation.
A => B
A => C
A invites with g711,g722 which is forked to B and C
B reports ringing by sending 183 + SDP g711
C report 180 ringing.
C establishes connection 200 OK + SDP g722
https://www.rfc-editor.org/rfc/rfc3261.html#page-78
o If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
Now we run into the situation in which A received the 183 g711 and
being RFC compliant, dropped the 2nd SDP from the 200 OK.
=> No audio!
Has anyone encountered this situation and found a nice solution? Like
generating an UPDATE or RE-INVITE towards A to change the codec in
an RFC compliant way after the call is established?
Or is the only solution to remove all codecs except the required g711a
one when more than one contact are registered on an AOR?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
15 Oct
15 Oct
1:58 p.m.
Hello,
On 15.10.24 09:41, Benoit Panizzon via sr-users wrote:
Hi Gang
Parallel forking situation.
A => B
A => C
A invites with g711,g722 which is forked to B and C
B reports ringing by sending 183 + SDP g711
C report 180 ringing.
C establishes connection 200 OK + SDP g722
https://www.rfc-editor.org/rfc/rfc3261.html#page-78
o If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
Now we run into the situation in which A received the 183 g711 and
being RFC compliant, dropped the 2nd SDP from the 200 OK.
=> No audio!
Has anyone encountered this situation and found a nice solution? Like
generating an UPDATE or RE-INVITE towards A to change the codec in
an RFC compliant way after the call is established?
Or is the only solution to remove all codecs except the required g711a
one when more than one contact are registered on an AOR?
this is a common scenario and the UAC (the phone) should be able to cope
with it.
By parallel forking, there will be two different To-tags, so practically
during the call setup, the UAC has to maintain two different
(early-state) dialogs, when one is answered with 200ok, the other one is
cancelled.
If the UAC that you use doesn't support parallel forking by downstream
proxies, then either you replace it with a capable one; configure it
with a single codec; as you suggested, strip codecs on proxy leaving a
single option; or route first via a transcoding system.
Cheers, Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
2:17 p.m.
Hi Daniel
this is a common scenario and the UAC (the phone)
should be able to cope
with it.
By parallel forking, there will be two different To-tags, so practically
during the call setup, the UAC has to maintain two different
(early-state) dialogs, when one is answered with 200ok, the other one is
cancelled.
If the UAC that you use doesn't support parallel forking by downstream
proxies, then either you replace it with a capable one; configure it
with a single codec; as you suggested, strip codecs on proxy leaving a
single option; or route first via a transcoding system.
The UAC in question, is the Swisscom Mobile Network.
I guess it's not feasible to tell Swisscom to replace all the millions
of mobile phones in operation. :-)
They tell me it's in the RFC, you side is not RFC compliant.
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
21 Oct
21 Oct
8:57 a.m.
Hello,
I think the Swisscom UAC is not acting RFC compliant in this case, but the standard is a
bit ambiguously phrased. The phrase related to the ignorance of any subsequent responses
is about the 18x and 200OK for each particular dialog, but not that you just accept the
first SDP that you receive and ignore the rest.
As per RFC:
13.2.2.4 2xx Responses
Multiple 2xx responses may arrive at the UAC for a single INVITE
request due to a forking proxy. Each response is distinguished by
the tag parameter in the To header field, and each represents a
distinct dialog, with a distinct dialog identifier.
Additional to the options mentioned from Daniel, you could also just remove all SDP from
provisional responses, but this will break early media obviously.
You maybe want to discuss this again with Swisscom, as it was a common error many years
ago also for German provider infrastructure, and got fixed after some time.
Cheers,
Henning
-----Original Message-----
From: Benoit Panizzon via sr-users <sr-users(a)lists.kamailio.org>
Sent: Tuesday, October 15, 2024 1:17 PM
To: Daniel-Constantin Mierla <miconda(a)gmail.com>
Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; Benoit
Panizzon <benoit.panizzon(a)imp.ch>
Subject: [SR-Users] Re: parallel forking: how to fix 183 g711 then 200 ok g722?
Hi Daniel
this is a common scenario and the UAC (the phone)
should be able to
cope with it.
By parallel forking, there will be two different To-tags, so
practically during the call setup, the UAC has to maintain two
different
(early-state) dialogs, when one is answered with 200ok, the other one
is cancelled.
If the UAC that you use doesn't support parallel forking by downstream
proxies, then either you replace it with a capable one; configure it
with a single codec; as you suggested, strip codecs on proxy leaving a
single option; or route first via a transcoding system.
The UAC in question, is the Swisscom Mobile Network.
I guess it's not feasible to tell Swisscom to replace all the millions of mobile
phones in operation. :-)
They tell me it's in the RFC, you side is not RFC compliant.
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
__________________________________________________________
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:
15 Oct
15 Oct
3:54 p.m.
Hi
Parallel forking situation.
Btw, exactly same issue also happens with serial forking.
A => B => C
A invites with g711/g722
B generates early 'ringback' audio g711 durcing 183
B times out, serial forking to C with inital SDP from A
B answers with g722
I agree with Daniel, that messages from C contain a different to tag
than the ones from B, so one could argue, this is not the same session.
But I doubt the companies building SBC takes such details into account.
In fact, I traced the issue again, our commercial SBC, operating in
B2BUA mode is using a different set of ToTag,FromTag on each leg and
the ToTag on the A leg are the same despite the ToTag on the B leg
being different after forking. So from A's point of view, an additional
SDP answer is receivedin the same session, which shall be dropped.
So, still wondering, is there a way so issue a Re-Invite or Update from
Kamailio?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
21 Oct
21 Oct
9:02 a.m.
Hello,
as frequently mentioned, Kamailio is a SIP proxy and not a B2BUA in its core. There are
some modules that implement limited B2BUA functions, like rtp_media_server.
But I think if you want to go that route you should look into another B2BUA, or as
suggested before use one of the other strategies.
Cheers,
Henning
-----Original Message-----
From: Benoit Panizzon via sr-users <sr-users(a)lists.kamailio.org>
Sent: Tuesday, October 15, 2024 2:54 PM
To: Benoit Panizzon via sr-users <sr-users(a)lists.kamailio.org>
Cc: Benoit Panizzon <benoit.panizzon(a)imp.ch>
Subject: [SR-Users] Re: parallel forking: how to fix 183 g711 then 200 ok g722?
Hi
Parallel forking situation.
Btw, exactly same issue also happens with serial forking.
A => B => C
A invites with g711/g722
B generates early 'ringback' audio g711 durcing 183 B times out, serial forking to
C with inital SDP from A B answers with g722
I agree with Daniel, that messages from C contain a different to tag than the ones from B,
so one could argue, this is not the same session.
But I doubt the companies building SBC takes such details into account.
In fact, I traced the issue again, our commercial SBC, operating in B2BUA mode is using a
different set of ToTag,FromTag on each leg and the ToTag on the A leg are the same despite
the ToTag on the B leg being different after forking. So from A's point of view, an
additional SDP answer is receivedin the same session, which shall be dropped.
So, still wondering, is there a way so issue a Re-Invite or Update from Kamailio?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
__________________________________________________________
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:
34
days inactive
40
days old
5 comments
3 participants
participants (3)
-
Benoit Panizzon -
Daniel-Constantin Mierla -
Henning Westerholt