Anonymous - 2012-07-03

Originally posted by: r3gis...@gmail.com

About point 1, it's usually linked to the sip provider. In fact CSipSimple allows you to configure some field that are defined in SIP protocol. Depending on the sip provider and the remote side field can have different meaning. On most betamax clones I tested the way I set the "caller-id" which in fact for regular SIP protocol is the SIP username produces that betamax sends this on regular landline calls as number.

On a regular sip client, it has all informations so it can display anything it wants.
If you want to play more with that here's what you can test :
Long press your account row in the list of accounts, select "Choose wizard" and choose "Expert".
Then simple click the row, and you'll see now a lot of settings to configure the account. Here you are at very lower level of SIP protocol and can configure everything that is normalized in SIP protocol. It made no assumption on the SIP provider.
Here you'll see several things,
the SIP ID : (aka AoR). It identify the sip user address. it's something like "Display Name" <sip:username@domain>

the < and > char are important. For betamax clones the "Display Name" is not taken into account while making a call, but the "username" is important. While on most other sip provider the username is the same than authentication name, here their servers allows you to use a different username than the authorization name.
On the PC receiver, as it get the complete "Display Name" <sip:username@domain> it can decide to display anything it wants. It really depend on the sip client you have on the other side. In CSipSimple I display the "display name", and try to resolve and search inside contacts using both display name and username.

You'll see also a "username/login" field in this mode. This one is the authentication name. It's what's is used to authenticate on betamax server. Normally no need to change it as correctly filled by the betamax wizard previous setup.

About point 2, it's probably because the sip server doesn't acknowledge the CANCEL. In this case, as the SIP dialog is not yet considered as finalized (because it's not acknoledged from other side that call was cancelled), the application stay in the call screen unless the SIP dialog times out. This timeout has a normalized value. So what you observe reflect the state of the call. Since cancel not acknowledged from other side, it remains like that. This can happens when there is some problem on server. It could also happen because of something with configuration. Maybe I can find a clue if you collect and send me logs. Turn on log collection, reproduce the problem, and just after stop and send logs :)

About point 3 :
For the particular point of "603/Decline" it's not a string from the application but from SIP protocol itself. So safer to keep it untranslated. However, you're right, many things are not fully translated in Spanish and I need help for translations :).
You can join translation effort here : https://www.transifex.net/projects/p/csipsimple/ . There's no team yet for spanish, so just request and I'll give you rights on the group.

Status: Need-Details