[OpenSIPS-Users] Bad from on header

[Mike Tesliuk]

Bogdan,

A last question about that, in this case, the ack does not match, so, the
dialog still in the memory right  ? will not be ended , and this can be the
problem that i have with memory on this server (too high memory usage)


2014-03-17 11:03 GMT-04:00 Mike Tesliuk <mike at ultra.net.br>:

> Ok Bogdan, thanks for you explanation, i will check that
>
>
> 2014-03-17 10:43 GMT-04:00 Bogdan-Andrei Iancu <bogdan at opensips.org>:
>
>  Yes, definitely that is the problem - that string is a B64 encoded
>> value, so it is case sensitive. According to RFC3261, UAs must copy the RR
>> params without any change (even if they do not understand). So your UAC is
>> broken when comes to handling RR headers.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>> On 17.03.2014 15:36, Mike Tesliuk wrote:
>>
>>     Ok,
>>
>>  I receive the invite, and i send the invite with this vsf
>> AAAAAF5CW0NKbgEAcAR4BxYLHgAABB0FGgA4
>>
>>  on the 180 is ok
>>  on the 183 is ok
>>  on the 200 is ok
>>
>>  The ack is ok, but lower case ( aaaaaf5cw0nkbgeacar4bxylhgaabb0fgga4 )
>>
>>  so everything broke
>>
>> From: <...S.m.z._6.A..^$..4.X.-.5.>;tag=1c731545057.
>>
>>
>>  The lower case on ACK can be the problem ?
>>
>>
>>
>> 2014-03-17 5:28 GMT-04:00 Bogdan-Andrei Iancu <bogdan at opensips.org>:
>>
>>>  Hello Mike,
>>>
>>> The restore/change of the FROM hdr is done automatically for the
>>> sequential requests. What I suspect in your case is an altering of the
>>> RR/Route "vsf" param - check if you have the same value in the outgoing
>>> INVITE (original), in the invite 200 OK (in RR hdr) and the incoming ACK
>>> (in Route hdr)
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>>   On 17.03.2014 00:03, Mike Tesliuk wrote:
>>>
>>>  Hello Bogdan,
>>>
>>>  Yes, on the initial request we have the uac_replace_from , but in this
>>> case the ack is not supposed to reach the function , as i say before, this
>>> does not happen on every dialog, just in some situation that i dont
>>> identify exactly which one yet.
>>>
>>>
>>> 2014-03-16 17:06 GMT-04:00 Bogdan-Andrei Iancu <bogdan at opensips.org>:
>>>
>>>>  Hello Mike,
>>>>
>>>> Are you using the uac_replace_from() for that call ?
>>>>
>>>> Regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>>
>>>>  On 14.03.2014 19:48, Mike Tesliuk wrote:
>>>>
>>>>     Hello Guys,
>>>>
>>>> Im checking about a problem here i hope somebody can help me.
>>>>
>>>>  Some times when i receive an ACK opensips is doing something strange
>>>> with the from, check the mesage below
>>>>
>>>>  Message that opensips has received
>>>>
>>>> U _CUSTOMER_IP_:5060 -> __OPENSIPS_IP__:5060
>>>> ACK sip:603#558533822977 at _ASTERISK_IP_:5060 SIP/2.0.
>>>> Contact: <sip:12345678 at 189.2.5.243:5060>.
>>>> CSeq: 1 ACK.
>>>> From: <sip:12345678 at 189.2.5.243>;tag=1c512295868.
>>>>
>>>>  Message that opensips has sended
>>>>
>>>> U __OPENSIPS_IP__:5060 -> _ASTERISK_IP_:5060
>>>> ACK sip:603#558533822977 at _ASTERISK_IP_:5060 SIP/2.0.
>>>> Contact: <sip:12345678 at 189.2.5.243:5060>.
>>>> CSeq: 1 ACK.
>>>> From: <...S.i.~.\..)..N(..24Y3-.9.>;tag=1c512295868.
>>>>
>>>>  With this, i get on my log  messages like below.
>>>>
>>>> ERROR:core:parse_to: unexpected char [\] in status 6: <<<#032??S?i?~?>>
>>>> .
>>>> ERROR:core:parse_from_header: bad from header
>>>>  ERROR:uac:restore_uris_reply: failed to find/parse FROM hdr
>>>>
>>>>  and the acc show me this
>>>>
>>>> reason=Call leg/transaction does not exist
>>>>
>>>>  i dont understand why this is happen, but happen just some times, and
>>>> as i can find just with one customer.
>>>>
>>>>
>>>>  if somebody can point me what kind of mistake can generate this error
>>>> i will apreciate.
>>>>
>>>>  Thanks
>>>>
>>>>
>>>>  _______________________________________________
>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140317/81818dc7/attachment-0001.htm>