"on_incoming_call" called twice for the same accountID issuing distinct callIDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi R?gis,

thank you very much for your prompt AND useful response!!

It was exactly as you predicted: the accounts were registered twice with the provider, I was able to verify that on their web-sites. And setting the contact_rewrite_method to legacy (1) did the "trick". - You made (at least) one person very happy tonight ;-) !!

Is there a "gentle" method to programmatically query a provider for the supported rewrite method? - One could certainly just try method "PJSUA_CONTACT_REWRITE_METHOD" and fall back to legacy (1) once duplicate incoming callbacks are detected - but that would not be "gentle"...

On the other hand: what is the real disadvantage of legacy (1)?

Again, thank you very much for your help!

-Thomas

ps: I had sent this message last night already - for unknown reasons, this had not been delivered ...

On Dec 11, 2010, at 01:52 , R?gis Montoya wrote:

> Not an expert too, but sounds something I've encountered many times :
> 
> Some SIP servers doesn't support the rewrite method for contact that do the NAT detection tip, used by pjsip (which is absolutely valid regarding RFC but just servers doesn't respect this part of the RFC).
> In this case, pjsip client is registered twice on the server and you can get 2 incoming calls at the same time !
> 
> The easier way to workaround that is to change contact rewrite :
> http://www.pjsip.org/pjsip/docs/html/structpjsua__acc__config.htm#a73b69a3a8d225147ce386e310e588285
> Try to use Legacy (1). It may help.
> 
> R?gis
> 
> Le 11/12/2010 00:23, Thomas Martin a ?crit :
>> Hello Everybody,
>> 
>> I have been wrestling  with this for a few days now - trying to locate my error:
>> 
>> Using 1.8.10 on both, OS X (10.6.5) and iOS4 to build a user-agent, my "on_incoming_call" procedure is called twice (within a few milliseconds) for the same incoming call targeting the same accountID issuing different callIDs (i.e. "0" and "1").
>> 
>> Out of pure desperation, I revived one of my first PJSIP trial-projects, using PJSIP 1.0.3 to compare this behavior in the same situation. As it turns out, the old project behaves 'decently' in the sense that "on_incoming_call" is only called once per incoming call.
>> 
>> I then replaced PJSIP 1.0.3 with the new PJSIP 1.8.10 to test, how the same old project behaves in this situation and voila: now "on_incoming_call" is also called twice for the same incoming call, without having changed even a single line of code (which -by the way- very closely follows the pjsua-reference-implementation for the "crucial" parts).
>> 
>> I must admit, though, I am not much of a SIP expert and -for the most part- rely on the PJSIP library documentation and functionality when it comes to SIP.
>> 
>> Therefore, I would really appreciate, if one of the experts could help me, identifying the cause of this strange and behavior. Have the semantics changed from 1.0.3 to 1.8.10 with respect to how incoming calls present themselves or are handled? - I doubt that I have discovered a bug in the library, since the effect is so obvious.
>> 
>> I almost forgot to mention, the described effect only happens to the accounts of certain providers (e.g. sipgate.de, sipgate.com).
>> 
>> Thank you very much in advance!
>> 
>> -Thomas
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>> 
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> 
> 
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
> 
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org




[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux