[Kamailio-Users] ACKed dialog remains in state 3 instead of 4

catalina oancea catalina.oancea at gmail.com
Sat May 30 08:51:48 CEST 2009


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. 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/
>
>




More information about the sr-users mailing list