[SR-Users] Kamailio, spiral with TM

[Klaus Darilion]

Am 08.07.2010 15:09, schrieb David:
> Hey,
>
> OK, so after further research, I found that the trouble was not in fact
> in the transaction, the trouble was with fix_nated_contact();
>
> So I setup a spiral SIP path. I have a public server that is used by a
> bunch of different phones, and I have a alg server ( one public and one
> private).
>
> The public server often handles NATed users and the private alg server
> handles NAT for a particular user set ( the users on that particular
> network) .
>
> The trouble is that the ALG does not rewrite the contact, rather it adds
> a Route: header with Record-Route. The trouble was the public server was
> calling fix_nated_contact on these users' requests, so when it came back
> and the last route header was parsed, the packet could not be delivered
> because the fix_nated_contact was changing the contact to the alg proxy
> server.
>
> I added a custom header called "X-Ignore-NAT", and when I do the nat
> tests ( nac_uac_test ), I also check that the X-Ignore-NAT header was
> not present.
>
> So I misdiagnosed the problem that I described in my message. I did my
> traces on the end point, so when I did not see the final packet arrive
> to the device, I thought it was being reabsorbed.
>
> Is the custom header I used a good solution?

If it works then it is a good solution. Custom headers are often used 
provider internally to signal arbitrary data. Just make sure if a user 
fakes the internal headers, that they are not able to exploit something 
in your setup - e.g. you should screen incoming messages for the 
existence of header names which will be used internally in your network 
- and if you found such headers, just remove them.

regards
klaus

>
> David
>
> On 10-07-08 07:04 AM, Klaus Darilion wrote:
>>
>>
>> Am 08.07.2010 00:53, schrieb David:
>>> Hey,
>>>
>>> I do not do anything IP level forwarding. All my forwarding is done
>>> using Kamailio. It looks like what I am doing is called hairpin routing.
>>
>> I think the correct term is "spiral" - at least the RFC uses this term.
>>
>> How do you forward the request - t_relay()? If yes, then tm module
>> should treat the request as a new transaction.
>>
>> Post a trace (you can rewrite IP addresses):
>> ngrep -t -q -W byline -d any -P "" port 5060 or 5061
>>
>> regards
>> Klaus
>>
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> On 2010-07-07 18:48, Timo Reimann wrote:
>>>> Hi,
>>>>
>>>>
>>>> David wrote:
>>>>> I have setup two Kamailio servers, my INVITEs will go through
>>>>> server A,
>>>>> which forwards to server B which forwards it back to server A.
>>>>>
>>>>> This is intential, the trouble is when the packet comes back through
>>>>> server B, nothing has changed so TM sees it as a retransmission.
>>>>>
>>>>> The difference between the first time through and the second time
>>>>> is the
>>>>> port 5061 instead of 5060.
>>>> If you forward the INVITE from B to A SIP-wise (e.g., by calling
>>>> forward()) a new Via header should be added which prevents the spiraled
>>>> INVITE message from being considered a retransmission on A.
>>>>
>>>> Do you perform forwarding on a lower level, like IP?
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> --Timo
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users