12 Mar
2014
12 Mar
'14
10:21 a.m.
Are you using the latest 4.1.x? There was a fix related to the counting
of the dialog in profile, by removing it from profiles when the call
gets to terminated state. The dialog is still kept for a bit in memory
after termination and was blocking new calls as the user appear to still
have another call in the same profile, although it was terminated.
I haven't checked commit logs, but iirc, quite some time ago someone
added the possibility to reuse the structure for authenticated dialogs,
but if you set the dialog in the profile for the second invite, then
should work.
Cheers,
Daniel
On 11/03/14 17:47, Alex Balashov wrote:
Something I should probably add:
On 03/11/2014 10:28 AM, Alex Balashov wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference - April 2-4, 2014, Berlin, Germany
http://www.kamailioworld.com
Hello,
We've got an issue we've been trying to track for days with 'dialog',
where the dialogs go through the following life cycle:
1. INVITE -->
2. <-- 407 challenge
3. ACK -->
4. INVITE -->
5. <-- 100 Trying
6. <-- 180 Ringing
7. <-- 183 Session Progress
8. <-- 200 OK
9. ACK -->
10. BYE -->
11. <-- 200 OK
The 407 challenge here is happening between the endpoints of the call;
it is not being done by the proxy. The proxy relays the 407 response
back to the caller, and the caller reoriginates the INVITE with
credentials, and that's passed back up to the UAS.
Aside from a different CSeq, these invites are the same. Would calling
dlg_manage() on both of them (which sets the profile count to 2) cause
them both to get deleted from the profile when the 407 challenge comes
back and is ACK'd? I would think not, since we call dlg_manage() again
when the INVITE with credentials is relayed.