39 lines
1.5 KiB
Plaintext
39 lines
1.5 KiB
Plaintext
Grammar:
|
|
* Grammar is not fully converted, see comments inside the grammar file
|
|
* UTF8 things not defined
|
|
|
|
Request/Response:
|
|
* Parse more Parameters properly...
|
|
|
|
Transaction:
|
|
* Cancel a Invite Transaction, stop responding to the 200.. or do it
|
|
with a bye...
|
|
* Invite can have multiple dialogs.. so we need to have a 'new dialog'
|
|
kind of signal...
|
|
* Route signals through the ok/cancel of the SIPDialog as a single entry
|
|
* Add responses...
|
|
* Add better state machine control, (do not allow to go back in states)
|
|
|
|
|
|
Dialog/Session/Route-Set:
|
|
* A dialog should have a route set (with the Via's)
|
|
* Does a dialog hold a session? a session holds a dialog?
|
|
* A call can go to session without having a confirmed dialog. This needs
|
|
to be looked at/denied. Do not ack a call that has no ;tag= attribute
|
|
for. One can remove the from ;tag in the "200 OK" test result to provoke
|
|
the failure in the testProxyAuth testcase.
|
|
|
|
General:
|
|
* 401 handling might not work for BYE,ACK. For ACK the ACK might not
|
|
be re-generated and the digest might be wrong due the missing operation
|
|
* 403 (maybe 401) should generate ACK on the 403 result? Check the RFC
|
|
if that is necessary! This would indicate why the branch is changing
|
|
_after_ the receiving 401/403. At the same time the proxy/server would
|
|
need to re-send the 401/403?
|
|
* Compare with MGCPCommands and share code... in SIPRequest
|
|
* Via we should indicate the received address and port...
|
|
|
|
|
|
* 3xx, 4xx, 5xx, 6xx are final. We should not allow any other messages.
|
|
Sending multiple 503/500 messages.. they all will be acked..
|