I'm trying to get Gnome Calls (its SIP support is based on sofia-sip NUA) to work with sipgate.de, with TLS enabled. The problem is that Sipgate rejects registration with Contact headers with sips: URLs. Unfortunately, that completely breaks Contact URLs generated with natify enabled.
So far, the only workaround I've found is to prepare the contact header myself and add
SIPTAG_CONTACT(SIP_NONE),
SIPTAG_CONTACT_STR(contact_header),
to the relevant calls: nua_register() (but I usually don't have the required information there yet), nua_authenticate() (after an "unauthorized" register response), nua_invite().
I can get the necessary information for NAT handling from the Via header in the "unauthorized" response, essentially replicating sip_contact_string_from_via() with the modification that TLS transport does not automatically produce a sips: schema.
Code duplication aside, the problem is that after setting SIPTAG_CONTACT_STR in the authenticate step the incorrect Contact headers keep showing up in responses to keepalive OPTIONS requests by the server, and then the registration expires quickly. If I already have the Contact URL when calling nua_register() (e.g. on reconnect, assuming the external IP of the NAT didn't change) and set it there, the Contact headers are correct.
So my questions are:
- What's the recommended way to override the
Contact header in a stable way? Is there a way to override the default in NUA, or a standard-compliant way to probe before register?
- Could
sip_contact_string_from_via() be fixed not to force sips: with transport=tls? I'm not sure if always using sip: might cause problems for other use cases, if yes, maybe a flag would be possible?
I'm trying to get Gnome Calls (its SIP support is based on sofia-sip NUA) to work with sipgate.de, with TLS enabled. The problem is that Sipgate rejects registration with
Contactheaders withsips:URLs. Unfortunately, that completely breaksContactURLs generated withnatifyenabled.So far, the only workaround I've found is to prepare the contact header myself and add
to the relevant calls:
nua_register()(but I usually don't have the required information there yet),nua_authenticate()(after an "unauthorized" register response),nua_invite().I can get the necessary information for NAT handling from the
Viaheader in the "unauthorized" response, essentially replicatingsip_contact_string_from_via()with the modification that TLS transport does not automatically produce asips:schema.Code duplication aside, the problem is that after setting
SIPTAG_CONTACT_STRin the authenticate step the incorrectContactheaders keep showing up in responses to keepaliveOPTIONSrequests by the server, and then the registration expires quickly. If I already have the Contact URL when callingnua_register()(e.g. on reconnect, assuming the external IP of the NAT didn't change) and set it there, theContactheaders are correct.So my questions are:
Contactheader in a stable way? Is there a way to override the default in NUA, or a standard-compliant way to probe before register?sip_contact_string_from_via()be fixed not to forcesips:withtransport=tls? I'm not sure if always usingsip:might cause problems for other use cases, if yes, maybe a flag would be possible?