Re: [SR-Users] parse_from_header(): bad From header

[Donat Zenichev]

Problem is solved.

The problem was in wrong regeneration of headers in ACK requests (uac
restore_mode parameter).
This parameter helps to modify From/To headers in all sequential requests
and replies in the same way as it has been modified in initial invite.

The uac from/to replacement relies that parties keep the same from/to
headers content.
The mechanism to replace A with B is to combine both and get the key X
which is added in the record-route as parameter.
Then practically from A and X results B and from B and X results A. It's
doing XOR over base64-encoded values.

And when endpoint or kamailio changes the mid dialog From or To URI, then
XOR against the key produces wrong values.


So the solution was to change this:
modparam("uac","restore_mode","auto")
modparam("uac","restore_dlg",1)

To this one:
modparam("uac","restore_mode","none")
modparam("uac","restore_dlg",0)

This case doesn't mean that uac module works improperly, of course no.
This means, that this options can only be used in topologies that can admit
such behavior.
In our case, kamailio changes $fU to internal numbers (before to send it to
an internal agent) for consistent callerid presentation.

So be careful while using such options in your topologies.




2017-11-16 15:42 GMT+02:00 Donat Zenichev :

> Hi Daniel.
> We are using now kamailio 4.4.6
>
> "the latest release series should have a safety check.." does it mean stable 
> 5.0.4 ?
> Well it is a reasonable advice I think, we haven't tried this way, yet.
>
> I thought about using uac + dialog module together, but this entails a lot of 
> changes in common logic.
>
> For that moment looks like disabling the restore_mode and restore_dlg 
> parameters solved the problem.
> So that, it is enough for me to keep calm. But further, I want to make an 
> effort to turn on dialog/uac modules together.
>
> Thanks for your answers.
> I will continue this topic as soon as I will start to work with it.
>
>
> >Hello,
> >
> >it would be useful to know also the version of kamailio that is run
> >there. The latest release series should have a safety check in order to
> >prevent setting an invalid restored From/To URI.
> >
> >On the other hand, if the UA doesn't preserve the From/To, then it
> >doesn't require to be unchanged, so the update (without auto restore) of
> >the From/To can be done only for initial INVITE, when UA takes the
> >caller/callee ids. For requests within the dialog, these headers can be
> >left unchanged or changed to something like anonymous at anonymous.invalid
> >
> >The last option here, which is the safest, is to use dialog module
> >together with uac, so uac module stores the From/To values inside the
> >dialog and restores them from there, instead of relying on
> >record-routing and the masking algorithm for values.
> >
> >Cheers,
> >Daniel
> >
> >>>On 14.11.17 08:04, Julia Boudniatsky wrote:
> >> Hello,
> >>
> >> It looks like headers "From" in initial INVITE and received message
> >> are different.
> >>
> >> For example:
> >>  in INVITE : >
> >>  in received message : >
> >>
> >> When you use header "From" transformation (I see Route with vsf),
> >> restore may be correct only for exactly the same header "From".
> >> Check may be port number is missing/added in  received message header
> >> "From".
> >>
> >> Best regards,
> >> Julia
> >>
> >> On Mon, Nov 13, 2017 at 5:05 PM, Donat Zenichev
> >> mailto:donat.zenichev at gmail.com wrote:
> >>
> >> Hi community.
> >> We experience the problem with malformed messages.
> >>
> >> First of all, I want to say, that most of time kamailio works well
> >> and nothing happens that can drop sessions.
> >> But from time-to-time something changes (may be in the network)
> >> and kamailio receives requests with malformed headers (To or From
> >> hfs).
> >>
> >> The schema:
> >> uplinks ->> kamailio <->> routing server (asterisk)
> >>
> >> Malformed messages were received only from asterisk server.
> >> Sip debug on asterisk showed that messages were transmitted
> >> correctly and headers were nice.
> >> But kamailio obtains changed (broken) packets or perhaps can't
> >> read them properly.
> >>
> >> How does it look like:
> >> Nov 10 12:37:06 kamailio-name kamailio[965]: INFO: 

Re: [SR-Users] parse_from_header(): bad From header

[Donat Zenichev]

Hi Daniel.
We are using now kamailio 4.4.6

"the latest release series should have a safety check.." does it mean
stable 5.0.4 ?
Well it is a reasonable advice I think, we haven't tried this way, yet.

I thought about using uac + dialog module together, but this entails a
lot of changes in common logic.

For that moment looks like disabling the restore_mode and restore_dlg
parameters solved the problem.
So that, it is enough for me to keep calm. But further, I want to make
an effort to turn on dialog/uac modules together.

Thanks for your answers.
I will continue this topic as soon as I will start to work with it.


>Hello,
>
>it would be useful to know also the version of kamailio that is run
>there. The latest release series should have a safety check in order to
>prevent setting an invalid restored From/To URI.
>
>On the other hand, if the UA doesn't preserve the From/To, then it
>doesn't require to be unchanged, so the update (without auto restore) of
>the From/To can be done only for initial INVITE, when UA takes the
>caller/callee ids. For requests within the dialog, these headers can be
>left unchanged or changed to something like anonymous at anonymous.invalid
>
>The last option here, which is the safest, is to use dialog module
>together with uac, so uac module stores the From/To values inside the
>dialog and restores them from there, instead of relying on
>record-routing and the masking algorithm for values.
>
>Cheers,
>Daniel
>
>>>On 14.11.17 08:04, Julia Boudniatsky wrote:
>> Hello,
>>
>> It looks like headers "From" in initial INVITE and received message
>> are different.
>>
>> For example:
>>  in INVITE : >
>>  in received message : >
>>
>> When you use header "From" transformation (I see Route with vsf),
>> restore may be correct only for exactly the same header "From".
>> Check may be port number is missing/added in  received message header
>> "From".
>>
>> Best regards,
>> Julia
>>
>> On Mon, Nov 13, 2017 at 5:05 PM, Donat Zenichev
>> mailto:donat.zenichev at gmail.com wrote:
>>
>> Hi community.
>> We experience the problem with malformed messages.
>>
>> First of all, I want to say, that most of time kamailio works well
>> and nothing happens that can drop sessions.
>> But from time-to-time something changes (may be in the network)
>> and kamailio receives requests with malformed headers (To or From
>> hfs).
>>
>> The schema:
>> uplinks ->> kamailio <->> routing server (asterisk)
>>
>> Malformed messages were received only from asterisk server.
>> Sip debug on asterisk showed that messages were transmitted
>> correctly and headers were nice.
>> But kamailio obtains changed (broken) packets or perhaps can't
>> read them properly.
>>
>> How does it look like:
>> Nov 10 12:37:06 kamailio-name kamailio[965]: INFO: 

Re: [SR-Users] parse_from_header(): bad From header

[Daniel-Constantin Mierla]

Hello,

it would be useful to know also the version of kamailio that is run
there. The latest release series should have a safety check in order to
prevent setting an invalid restored From/To URI.

On the other hand, if the UA doesn't preserve the From/To, then it
doesn't require to be unchanged, so the update (without auto restore) of
the From/To can be done only for initial INVITE, when UA takes the
caller/callee ids. For requests within the dialog, these headers can be
left unchanged or changed to something like anonymous@anonymous.invalid

The last option here, which is the safest, is to use dialog module
together with uac, so uac module stores the From/To values inside the
dialog and restores them from there, instead of relying on
record-routing and the masking algorithm for values.

Cheers,
Daniel


On 14.11.17 08:04, Julia Boudniatsky wrote:
> Hello,
>
> It looks like headers "From" in initial INVITE and received message
> are different.
>
> For example:
>  in INVITE : 
>  in received message : 
>
> When you use header "From" transformation (I see Route with vsf),
> restore may be correct only for exactly the same header "From".
> Check may be port number is missing/added in  received message header
> "From".
>
> Best regards,
> Julia
>
> On Mon, Nov 13, 2017 at 5:05 PM, Donat Zenichev
> > wrote:
>
> Hi community.
> We experience the problem with malformed messages.
>
> First of all, I want to say, that most of time kamailio works well
> and nothing happens that can drop sessions.
> But from time-to-time something changes (may be in the network)
> and kamailio receives requests with malformed headers (To or From
> hfs).
>
> The schema:
> uplinks -> kamailio <-> routing server (asterisk)
>
> Malformed messages were received only from asterisk server.
> Sip debug on asterisk showed that messages were transmitted
> correctly and headers were nice.
> But kamailio obtains changed (broken) packets or perhaps can't
> read them properly.
>
> How does it look like:
> Nov 10 12:37:06 kamailio-name kamailio[965]: INFO: 

Re: [SR-Users] parse_from_header(): bad From header

[Julia Boudniatsky]

Hello,

It looks like headers "From" in initial INVITE and received message are
different.

For example:
 in INVITE : 
 in received message : 

When you use header "From" transformation (I see Route with vsf), restore
may be correct only for exactly the same header "From".
Check may be port number is missing/added in  received message header
"From".

Best regards,
Julia

On Mon, Nov 13, 2017 at 5:05 PM, Donat Zenichev 
wrote:

> Hi community.
> We experience the problem with malformed messages.
>
> First of all, I want to say, that most of time kamailio works well and
> nothing happens that can drop sessions.
> But from time-to-time something changes (may be in the network) and
> kamailio receives requests with malformed headers (To or From hfs).
>
> The schema:
> uplinks -> kamailio <-> routing server (asterisk)
>
> Malformed messages were received only from asterisk server.
> Sip debug on asterisk showed that messages were transmitted correctly and
> headers were nice.
> But kamailio obtains changed (broken) packets or perhaps can't read them
> properly.
>
> How does it look like:
> Nov 10 12:37:06 kamailio-name kamailio[965]: INFO: 

Re: [SR-Users] parse_from_header(): bad From header

[Julia Boudniatsky]

Hello,

It looks like headers "From" in initial INVITE and received message are
different.
For example:
 in INVITE : 
 in received message
When you use header "From" transformation ( Route with vsf), restore may be
correct only for exactly the same header "From" format.
For example
Check may be port number is missing/added in "From" received message.


On Mon, Nov 13, 2017 at 5:05 PM, Donat Zenichev 
wrote:

> Hi community.
> We experience the problem with malformed messages.
>
> First of all, I want to say, that most of time kamailio works well and
> nothing happens that can drop sessions.
> But from time-to-time something changes (may be in the network) and
> kamailio receives requests with malformed headers (To or From hfs).
>
> The schema:
> uplinks -> kamailio <-> routing server (asterisk)
>
> Malformed messages were received only from asterisk server.
> Sip debug on asterisk showed that messages were transmitted correctly and
> headers were nice.
> But kamailio obtains changed (broken) packets or perhaps can't read them
> properly.
>
> How does it look like:
> Nov 10 12:37:06 kamailio-name kamailio[965]: INFO: