Support forking SIP calls #227
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a SIP call is forked, the client will send an INVITE with the same Call ID and same From tag as an earlier INVITE, but with a different Branch ID in the topmost Via header. There were two issues with sofia-sip which prevented call forking from working; first, its logic for merging SIP requests (as per RFC3261 section 8.2.2.2) did not respect the Branch ID. It would merge requests with a different Branch ID, which is contrary to RFC3261 section 17.2.3. Second, sofia-sip has some logic for checking whether incoming requests are part of an established SIP dialog or not. The matching criteria were such that incoming INVITE requests forking a call would be treated as part of the already established dialog, and then an error would be returned to the client, essentially telling the client that this new INVITE is invalid because the call is already established. Therefore, add some extra matching conditions which ensure that an INVITE forking a call will not be treated as part of the previously established call leg. The matching conditions are as specific as possible, to minimize the chances of unintentionally affecting how other types of SIP messages are handled. Implementing these new matching conditions can only be done by recording the Branch ID for established calls, so we can check whether another INVITE which comes later has the same Branch ID or a different one. This requires adding a new member to nta_leg_s. Co-Authored-By: João Arruda <joao.arruda@gmail.com>
|
Great work @alexdowad @andywolk how we can have this reviewed? |
|
Will this also fix #211? |
Yes, it will. |
algitbot
pushed a commit
to alpinelinux/aports
that referenced
this pull request
Aug 28, 2023
algitbot
pushed a commit
to alpinelinux/aports
that referenced
this pull request
Aug 28, 2023
ref: freeswitch/sofia-sip#227 (cherry picked from commit 143c519)
algitbot
pushed a commit
to alpinelinux/aports
that referenced
this pull request
Aug 28, 2023
ref: freeswitch/sofia-sip#227 (cherry picked from commit 143c519)
algitbot
pushed a commit
to alpinelinux/aports
that referenced
this pull request
Aug 28, 2023
ref: freeswitch/sofia-sip#227 (cherry picked from commit 143c519)
algitbot
pushed a commit
to alpinelinux/aports
that referenced
this pull request
Aug 28, 2023
ref: freeswitch/sofia-sip#227 (cherry picked from commit 143c519)
|
As suggested in the last FS Community Call please find attached a sipp scenario that can be used to see the problem before the patch and it working after the patch. That scenario assumes you have 2 extensions registered in FS (1234 and 1235). An INVITE is sent to 1234 and after 10 seconds ringing (do not answer it) it will fork the call to 1235 (new INVITE with a different branch parameter in Via header) and later CANCEL the original INVITE. Before the proposed patch you will see that the second INVITE will be replied with After applying the proposed patch the second INVITE will be processed as as expected. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a SIP call is forked, the client will send an INVITE with the same Call ID and same From tag as an earlier INVITE, but with a different Branch ID in the topmost Via header.
There were two issues with sofia-sip which prevented it from handling multiple INVITE requests for forked SIP calls; first, its logic for merging SIP requests (as per RFC3261 section 8.2.2.2) did not respect the Branch ID. It would merge requests with a different Branch ID, which is contrary to RFC3261 section 17.2.3.
Second, sofia-sip has some logic for checking whether incoming requests are part of an established SIP dialog or not. The matching criteria were such that incoming INVITE requests for forked calls would be treated as part of the already established dialog, and then an error would be returned to the client, essentially telling the client that this new INVITE is invalid because the call is already established.
Therefore, add some extra matching conditions which ensure that an INVITE establishing a forked call will not be treated as part of the previously established call leg. The matching conditions are as specific as possible, to minimize the chances of unintentionally affecting how other types of SIP messages are handled.
Implementing these new matching conditions can only be done by recording the Branch ID for established calls, so we can check whether another INVITE which comes later has the same Branch ID or a different one. This requires adding a new member to nta_leg_s.
My goal here is to allow FreeSWITCH (via
mod_sofia) to be able to successfully proxy INVITE requests for forked SIP calls, when both destinations of the forked call are behind the same FreeSWITCH instance. However, it also means that all other users oflibsofiawill potentially be able to handle forked calls as well.