200 OK response does not contain username in contact header

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Make call to cSIPsimple station from SIP Server station
2.Slide to answer call
3.

What is the expected output? What do you see instead?  In version 01.01, the 
200 OK response contained a username in the contact header.  In version .02-01 
r841, it does not.

What version of the product are you using? On what operating system?  02-01 r841
Android 2.2

Please provide any additional information below.
I noticed that when I upgraded, the contact header still contained the 
username, but when I enabled "support multiple calls" in "calls options", the 
username is no longer inserted in the contact header.  Disabling "support 
multiple calls" did not fix the issue.

Original issue reported on code.google.com by joll...@iconvn.com on 25 May 2011 at 11:46

[GoogleCodeExporter]

Normally it's not linked to the support multiple call option. This one is about 
something that is done on the top of the sip stack and your issue sounds to me 
more related to the sip stack itself (pjsip) or its configuration (I mean even 
the configuration I do in the application space).

Your problem could be linked to the fact the more recent versions also create 
some "local account" for SIP to SIP calls. This is done automatically and is 
not configurable.
Previously the only account known by the sip stack was the one you configured. 
However it produced several problems.
As consequence, as it's advised by pjsip stack I created automatically two 
accounts one for TCP and one for UDP for inbound sip calls.

When some call reach the pjsip stack, it tries to detect the account this call 
comes from. And then once it knows from which account it comes, apply the 
account settings to the reply (specially the contact header).

If it comes from the register socket it should be obvious (to say the truth I 
didn't deep really in this part of code but I guess it should work in this 
case). 
If it comes from somewhere else (even the one of your server itself that bind 
the local bindings of pjsip), it's less obvious and the stack has to inspect 
what is sent in the invite to try to detect from where it comes.
In this case usually headers of the INVITE are usefull to detect either via or 
the other contact and so on (again I don't know exactly how pjsip detect that 
but it tries to do).
If none of the accounts match (probably your case), it take the fallback 
account which is the local one. And communicate with your remote party as if it 
was a direct sip call and in this case no username.

If you want to send me logs (see HowToCollectLogs wiki page) I'll be able to 
investigate a little bit more deeper why pjsip does not retrieve your remote 
party as belonging to a sip account and maybe propose a workaround for this 
kind of case.

Original comment by r3gis...@gmail.com on 26 May 2011 at 7:57

[GoogleCodeExporter]

I sent the logs.  I have packet captures, also, if necessary.

Original comment by joll...@iconvn.com on 26 May 2011 at 1:56

[GoogleCodeExporter]

I found my problem.  The account id was set to the server ip address from
the basic configuration.  This is the field it checks against the to header
or request uri on an incoming call.  I had to change it in the expert
configuration.  However, this would be difficult to change.  It is easier on
my test system as I have static IP addresses, but in a normal customer
implementation, this would not be possible.  Am I programming the phone
incorrectly when setting the account or is this a bug?

I still have the same problem with incoming calls, but now, at least, I have
a username in my contact header.

Original comment by joll...@iconvn.com on 26 May 2011 at 4:33

[GoogleCodeExporter]

In the account information, what do I need to set to verify the account?
 Currently, the account ID is set to 4699@phone ip address.  This works and
uses the correct account instead of the default one.  However, this will not
work if I use DHCP for the phone.  What entry does it look at for the
account information (i.e.:  request uri, to header, from header, etc.)?

Original comment by joll...@iconvn.com on 27 May 2011 at 6:03

[GoogleCodeExporter]

Yeah, in fact the problem should be solved more on the other side than on 
csipsimple side.

Here is how it should work :
CSipSimple register to the registrar with the ID 4699@registrar_ip_or_domain.
When somebody tries to call 4699 it has to call 4699@registrar_ip_or_domain.
and in consequence the to header must contain 4699@regisistrar_ip_or_domain and 
pjsip will understand this comes from what it has previously registered and 
detect it's this account cause the account id matches the To field.

In your case the remote party does not call 4699@registrar_ip_or_domain but 
4699@phone_ip. 

It works with csipsimple cause csipsimple has a local account that listen 
locally on the phone. (it allow sip to sip direct calls). In this case no 
matter of the 4699 in fact cause for csipsimple the account id is just 
sip:phone_ip (obviously no need of username here cause it's a client and there 
is only one user on it).

This kind of case could be linked to either the remote party or the 
configuration of your sip registrar/server.

I don't know what is the IP of your sip server but I guess it's the 
xxx.xxx.xxx.1 . If so it would mean that it transmit INVITE requests without 
taking into account a sip domain but just considering sip ua.
So it could be something linked to the sip server config itself.

Or second possiblity it could be linked to your remote party (if your remote 
party has the xxx.xxx.xxx.1 IP). In this case it's cause this remote party uses 
the phone IP instead of the registrar IP (I guess all your conf is about IP and 
there is no domains). 
Normally the remote party should dial sip:4699@registrar_ip but here it calls 
4699@phone_ip. 
Obviously in this case no need of registrar ;) and pjsip considers it comes 
from a direct sip to sip call and replies as it should with the local account 
instead of the one it has registered. 

It make sense cause from the point of view of pjsip, the other side does not 
need the registrar cause the incoming invite is done as if it waas a sip to sip 
client call.

Original comment by r3gis...@gmail.com on 29 May 2011 at 11:34

• Changed state: WrongConfig

[GoogleCodeExporter]

The to: header should contain the proxy address or the ip address of the
phone when the call is incoming to the phone.  In the case of an incoming
call, it should be the from header ip address or just "authorize" using the
user name.

Original comment by joll...@iconvn.com on 31 May 2011 at 3:21