[SR-Users] Kamailio, spiral with TM

[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?

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