We would need to have SIPParameter as a baseclass that works without
having a dataobject. Right now this is a duck-type as it implements
the used methods.
This only implements one of the possible approaches for the digest
handling. This is a very simple test and the choiche of the same
username/password was a bit unfortunate.
Update the grammar to handle the WWW-Authenticate according to the
RFC. Add the parser to compact everything into a Dictionary. Add the
realm last to avoid being overwritten with another parameter.
SWS is optional and will always match. This means the SWS rule
would match everything and we would never finish. Norbert has
pointed out that an optional element will match but not consume
anything. One should avoid a rule like aParser optional plus.
These generate random strings so it is difficult to unit test. But
the invocation worked:
st> Osmo.SIPRandomHelper generateTag
'MzU0MjIxMTQ1OTIzODI1ODc3NjU_'
st> Osmo.SIPRandomHelper generateCallId
'MTk3MTU3OTAxOA__@xiaoyu'
st> Osmo.SIPUserAgent generateBranch
'z9hG4bKMzU0MjIwNDM2Myw0MjIxNg__'
* Change the category for the tests and extensions
* Rewrite usages of >>nl and >>cr
* There are still issues with the Socket code, Datagram handling
and and expands.
Use DatagramSocket>>ensureReadable as this is using async poll,
make sure the socket is still open after ensureReadable returns.
Move the RX/TX into selectors as this allows us to return from
them.
The class was called SIPSecureRandom as it used /dev/random for
random numbers. The downside of /dev/random is that a read can
block until enough data has been generated. This does occur, e.g.
on an isolated system. Start using /dev/urandom for the tags. It
is better than the Mersene twister of GST but it is no source
for key material.
* This isn't doing proper routing (e.g. the via is not modified
properly but we return it to the right address)
* An unknown BYE will be acked with a 481. The 'respondWith:...'
includes the wrong 'Allow:' but it is good enough from the
structure for now.
* Re-Order the loading of files as the SIPUserAgent is extended
the SIPRequests.
* Add the port/ip to the SIPDialog so that responding to the
request is possible.
The name session base is a bit misleading as it is not the session
that holds the initial dialog, the confirmed dialog, the UAS and then
also the session when it is setup. When the dialog gets confirmed we
will register it with the useragent and then will be called for new
requests. On hangup/cancel the dialog will be scheduled for removal.
Constructing a PetitParser is an expensive operation (Object>>becomeForward:)
we can keep the parser in the class. For the SIPTransactions we keep it as
a global, it is assumed that all SIPTransactions operate through the same
process and will not run into concurrency issues.
This is still more complicated (and wrong) then it should be,
when we CANCEL an INVITE we can either send a CANCEL or we need
to wait for a 100. Now the CANCEL could be too late (the server
already sent a 200), in that case we would get a 200 for the
INVITE and pass this to the higher levels (which we probably
should).
Holger Hans Peter Freyther