[OpenSIPS-Users] Bad from on header

[Bogdan-Andrei Iancu]

Yhe ACK matches the dialog, but the UAC module is not able to do a 
correct restore / change of the FROM header.

BTW, try to do the FROM stuff after creating the dialog -> in this case, 
the B64 value will be stored in the dialog and not in the RR header.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 17.03.2014 17:17, Mike Tesliuk wrote:
> 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 
> <mailto: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 <mailto: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 Developer
>         http://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 <mailto: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 Developer
>>             http://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 <mailto:bogdan at opensips.org>>:
>>>
>>>                 Hello Mike,
>>>
>>>                 Are you using the uac_replace_from() for that call ?
>>>
>>>                 Regards,
>>>
>>>                 Bogdan-Andrei Iancu
>>>                 OpenSIPS Founder and Developer
>>>                 http://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
>>>>                 <http://sip:12345678@189.2.5.243:5060>>.
>>>>                 CSeq: 1 ACK.
>>>>                 From: <sip:12345678 at 189.2.5.243
>>>>                 <mailto:sip%3A12345678 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
>>>>                 <http://sip:12345678@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 list
>>>>                 Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>>>                 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140317/b25b0b51/attachment-0001.htm>