In case our reject does not arrive and is re-transmitted we
should reject it too.
* Modify SIPDialog>>#checkCompatible. We have to accept that
the remote does not know the tag we assigned. Be more forgiving
* Send the INVITE again and count our rejects.
Create a SIPIncomingCall and register the dialog. The "Via" and
remote handling is broken. The "respond with" is broken too. The
whole dialog/request passing to the UserAgent is broken and needs
to be fixed.
I nee to differentiate between incoming and outgoing calls. At
the same time a lot of logic can be shared. Specially at the
time the call is established the hangup will work the same on
both sides.
A rule like "ANY star / quoted_string" will only parse the ANY
rules for '0' times. Change the order to avoid this and add a
small test that we properly parse the From address now.
token requires the presence of at least one match. The usage of
star has been wrong and is corrected now. This was seen due not
being able to parse a From address that included a diplay name.
Remove the trailing ";" to fix the parsing bug.
When we receive a message and there is rport and such set we
should include the "seen" remote address in the VIA. The code
should also handle having multiple VIA entries as per the spec.
The code allows (and that looks like a good thing) to have a different
from and username in the authorization. The userString was not really
right as it was missing the URL part (sip/sips) and the splitting was
broken as well.
In preparation of introducing multiple identities we need to
remove usage of SIPUserAgent>>#username. The next step is to
actually be able to pass a different identity.
The Transport to UserAgent relationship is a one to one. E.g. we
need this to generate unique branch and call-ids to make sure the
dialogues are different. To be able to use multiple identities I
introduce a SIPIdentity class. Currently the user agent has one
main identity but this could change over time.
Pass in the dialogue from the lower layer to make sure to respond
to the right party (including the from/to being in the right order).
Implement the re-invite that is needed to keep a phone call alive
for more than 45 seconds on this system.
Add a testcase for testing ProxyAuthenticate and ProxyAuthorize,
extend the grammar and parser to handle the needed bits. Document
another error/failure with the dialog handling code and create a
testcase that fully connects a call.
* -> INVITE
* <- 100 Trying
* -> Cancel
* <- 200 ACK
* -> OK
* <- 100 Trying
...
* <- 463 Timeout
and we would run through the same circle again. Instead opt for
a simple work-around right now and remember if we canceled once.
We should spawn a transaction and remember the result.
To support servers behind a NAT we need to include the rport
parameter in our via. This way the server will respond to us
on the sourceport it got the message from.
We will probably need to implement the same and return the
sourceport as rport=1234 to the other end.
The SIP RFC specifies that after a final response everything should
be ignored. It is not clear if an ACK should be sent for a 503 message
or if the dialog has been terminated. It looks like for 4xx, 5xx and
6xx the dialogue is gone. No ack needed.
We must extend the grammar to add caseInsensitive to a lot of
fields as they are case-insensitive as part of the specification
this even applies to some parameter names where expires and
eXpiReS are considered to be the same. Start with the simple
case of the parameter.
Avoid infinite auth retries and remember if the last message has
been an authentication request. Ignore the 100 TRYING like messages
as they do not add much value.
Holger Hans Peter Freyther