Closed vodik closed 6 years ago
Merging #81 into master will increase coverage by
0.84%
. The diff coverage is73.63%
.
@@ Coverage Diff @@
## master #81 +/- ##
==========================================
+ Coverage 70.45% 71.29% +0.84%
==========================================
Files 14 14
Lines 1479 1512 +33
Branches 260 264 +4
==========================================
+ Hits 1042 1078 +36
Misses 327 327
+ Partials 110 107 -3
Impacted Files | Coverage Δ | |
---|---|---|
aiosip/application.py | 68.84% <100%> (-1.45%) |
:arrow_down: |
aiosip/peers.py | 68.87% <65%> (+0.58%) |
:arrow_up: |
aiosip/transaction.py | 62.75% <69.23%> (+1.04%) |
:arrow_up: |
aiosip/dialog.py | 77.51% <74.85%> (+2.75%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 7eae6f8...39e21a3. Read the comment docs.
Merging this so I can start playing with this on Monday. Probably will end up moving to @ovv's suggested API but want to see first if having the distinction is useful.
Closed #77 and creates a new one because I ended up taking a slightly different approach with deeper changes that I'm more happy with.
This PR starts by reworks the dialog API so it must be paired with an initial message. This lets me removes the private
_subscribe
and_register
methods in favour of a newrefresh
andclose
API that sends the right follow up message with the right "Expires" header.Then I implement some basic INVITE dialog support. This requires its own dialog class implementation as it has its own call state information that needs to be tracked. INVITE really is a special case, and thus needs to be treated differently.
I think this lends itself a lot better to having a good REGISTER/SUBSCRIBE client API, but its also making it more and more clear that we need different abstractions for server and client dialogs. Currently they're represented by the same abstraction, but they're setup and operation is slightly different.
The INVITE support it also not perfect. We do not properly handle ACK yet, and I've taken to just suppressing the warning message instead. I'll continue to work on this, but for the moment I want to start using the INVITE APIs and see if they're actually sensible.