Otherwise we might miss the IP of the remote peer leaving us unable to
establish a connection for RTP.
From https://datatracker.ietf.org/doc/html/rfc4566#section-5.7
A session description MUST contain either at least one "c=" field in
each media description or a single "c=" field at the session level.
It MAY contain a single session-level "c=" field and additional "c="
field(s) per media description, in which case the per-media values
override the session-level settings for the respective media.
The assumption that the IP of the remote peer can always be found in the
sdp_connection member of the sdp_session_s struct does not always hold true
and we should handle this case gracefully (i.e. without crashing).
This makes sure all of the supported protocols have a chance of working.
Since nua_set_params does not update NUTAG_URL (carefully rechecking the docs
verifies this), it is safe to remove the code in update_nua().
However, this means that we will have to recreate the nua stack,
which incidentally is currently being worked on:
https://gitlab.gnome.org/GNOME/calls/-/merge_requests/402
All parts not related to credentials are now being set when creating the nua
handles and then updated with nua_set_params() when the credentials get updated.
Shuffle the code around and make use of docstrings to conform to
the newly introduced coding style as described in `HACKING.md`
This commit also introduces docstrings describing each source file.
introduce `calls_sip_media_manager_get_capabilities ()` which takes
a GList of MediaCodecInfo's as input to generate a SDP message.
If using in an SDP answer we simply feed it a list of the common codecs
as gathered from the SDP offer.
by making sure the call-added signal is emitted early enough
so that all consumers (display, ringer, etc) have a chance of getting
notified when the call state changes from f.e. DIALING to DISCONNECTED
similar to how its done in 03d960ccaf
for the dummy provider.
* removed nua_callstate_authenticating as it was never hit
* move debug statement further up, because we might not reach it if no
corresponding call is found
* handle 401 and 407 the same way
note: we should record which realm we're authenticating against during
REGISTER so we can prompt the user for additional credentials when
challenged for a different realm - still happens when calling from
a sip.linphone.org account to a jmp.bwapp.bwsip.io account.
IPv6 should work, but sofia's outbound engine keep printing
errors involving the outbound engine. Working theory:
Failing ICMPv6 (pings) can make sofia think we don't have connectivity.
Note that we also don't get any answers from the SIP servers we tried so far.
