[Kamailio-Users] ACKed dialog remains in state 3 instead of 4
Daniel-Constantin Mierla
miconda at gmail.com
Sat May 30 10:19:44 CEST 2009
Hello Catalina,
On 05/30/2009 09:51 AM, catalina oancea wrote:
> Hi Daniel,
>
> The cseq is increased by one when the second INVITE arrives. I think
> this should be fixed in the code because others may experience the
> same problem. I tested with modified code, which didn't stop the
> search when the dialog was found with deleted state and it was all OK,
> the problem no longer appeared, but I'm not sure this is an efficient
> solution.
please register the patch on the tracker. There are some bugs reported
that I am going to fix and I will check the patch as well and the
eventual side effects.
Cheers,
Daniel
> It would be better to simply delete dialogs from the list
> when the INVITE receives 4xx-6xx answers instead of just marking them
> as deleted. But I don't know the code so well, it's your call.
>
> Thanks for answering
> Catalina
>
>
>
>
> 2009/5/29 Daniel-Constantin Mierla <miconda at gmail.com>:
>
>> Hello,
>>
>> On 05/28/2009 02:48 PM, catalina oancea wrote:
>>
>>> Hi Daniel,
>>>
>>> Actually reading RFC 3261 I see that the same callid must be used:
>>>
>>> This
>>> Note that when requests are retried after certain
>>> failure responses that solicit an amendment to a request (for
>>> example, a challenge for authentication), these retried requests are
>>> not considered new requests, and therefore do not need new Call-ID
>>> header fields;
>>>
>>>
>> hmm, even the from tag should be preserved? What is the cseq in your case?
>>
>>
>>> I tried xlog to print $dlg(ref) when receiving 407, in the
>>> failure_route (actually it's 401, but that doesn't matter) and it
>>> printed <null>.
>>>
>>>
>> ahh, right, the 401 is coming from downstream, it is not replied by
>> kamailio.
>>
>>
>>> I also printed the dialogs using mi-fifo after the call was and it
>>> only showed one dialog.
>>>
>>> I don't know how long the first dialog lasts but I am sure that it is
>>> in the list because I added a debug message in the source printing
>>> "dialog_deleted" when the dialog is found and it is in state deleted.
>>>
>>> Why is it in state deleted and not actually removed? Why does the
>>> search stop when the dialog is found but it is in state deleted? And
>>> shouldn't there be only one dialog for both INVITEs, since, the callid
>>> and from tag is the same?
>>>
>>>
>> First dialog ended with 401, so cannot take new requests within.
>>
>> In this particular case could make sense continue searching.
>>
>> Cheers,
>> Daniel
>>
>>
>>> Many thanks,
>>> Catalina
>>>
>>>
>>> 2009/5/28, Daniel-Constantin Mierla <miconda at gmail.com>:
>>>
>>>
>>>> Hello,
>>>>
>>>> On 05/27/2009 06:44 PM, catalina oancea wrote:
>>>>
>>>>
>>>>> Yeah ok, but this is not the issue here.
>>>>>
>>>>> Even if I use record-routing, if I don't use the fast-matching cookie,
>>>>> the problem I described still remains.
>>>>>
>>>>>
>>>>>
>>>> as I got from the diagram in your first email, second call, coming after
>>>> 407, preserves the call-id and from tag?
>>>>
>>>> According to RFC, this is a completely new dialog and should use
>>>> different values.
>>>>
>>>> Anyhow, after you send back the challenge, can you print with xlog
>>>> $dlg(ref) and paste it here? Is the ended dialog staying for long time
>>>> (you can use mi to list dlgs)?
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>>
>>>>> 2009/5/27 Alex Balashov <abalashov at evaristesys.com>:
>>>>>
>>>>>
>>>>>
>>>>>> Catalina,
>>>>>>
>>>>>> catalina oancea wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> From what I know the record-route header is not compulsory, and
>>>>>>> dialog-matching can also be done using rfc dialog-matching instead of
>>>>>>> the did parameter in record-route (modparam("dialog",
>>>>>>> "dlg_match_mode", 2)). This is what I am trying to use, I don't want
>>>>>>> to use the record-route header at all.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> It is true that you do not have to use the dialog fast-matching cookie
>>>>>> parameter in the Record-Route header.
>>>>>>
>>>>>> However, you need the Record-Route header in order for the proxy to
>>>>>> have
>>>>>> visibility into subsequent sequential requests within the dialog, so
>>>>>> you
>>>>>> might as well use the parameter for faster matching.
>>>>>>
>>>>>> In other words, if you don't add Record-Route, your proxy won't see
>>>>>> BYEs,
>>>>>> re-INVITEs, etc. See RFC 3261 20.30
>>>>>> (http://www.ietf.org/rfc/rfc3261.txt):
>>>>>>
>>>>>> 20.30 Record-Route
>>>>>>
>>>>>> The Record-Route header field is inserted by proxies in a request to
>>>>>> force future requests in the dialog to be routed through the proxy.
>>>>>>
>>>>>>
>>>>>> -- Alex
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alex Balashov
>>>>>> Evariste Systems
>>>>>> Web : http://www.evaristesys.com/
>>>>>> Tel : (+1) (678) 954-0670
>>>>>> Direct : (+1) (678) 954-0671
>>>>>> Mobile : (+1) (678) 237-1775
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Kamailio (OpenSER) - Users mailing list
>>>>> Users at lists.kamailio.org
>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Daniel-Constantin Mierla
>>>> http://www.asipto.com/
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Kamailio (OpenSER) - Users mailing list
>>> Users at lists.kamailio.org
>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>> --
>> Daniel-Constantin Mierla
>> http://www.asipto.com/
>>
>>
>>
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>
>
--
Daniel-Constantin Mierla
http://www.asipto.com/
More information about the sr-users
mailing list