[Serusers] Error 483 response to ACK and BYE

[SIP]

Right. That's the part that's difficult to discover. Where the problem 
lies.

The INVITE gets there correctly...  I see the path.

UA ---> INVITE 1101201 ---> other proxy ---> INVITE 201 ---> our 
proxy:5060 ---> INVITE 201 ---> our proxy:5090 ---> 200 OK

The ACK, however, takes a slightly different path:

other proxy ---> ACK 201 ---> our proxy:5060 ---> ACK 201 ---> our 
proxy:5060 ---> rinse ---> repeat

However, from locally registered clients, the path is:

UA ---> ACK 201 ---> our proxy:5060 ---> ACK 201 ---> our proxy:5090 
---> life is good.

It's the whole discrepancy that throws me. I mean... the SIP messages 
are, for all intents and purposes, going through the same config. I 
can't figure out why one client would not experience the same issues as 
any other client, locally registered or not.

The Contact header response from the INVITE is correct:

Contact: <sip:201 at 63.64.65.66:5090>.


But then, the INVITE goes through a series of rewrites of the host/port 
based on the URI before t_relay. ACKs just go straight to t_relay. I 
guess I'm not 100% sure who writes/rewrites the Contact header.

N.

Andres wrote:
> Andres wrote:
>
>> SIP wrote:
>>
>>  
>>
>>>   setflag(3);    if (!t_relay())    {       sl_reply_error();    };
>>> }
>>>
>>> But for some reason, it sends it to itself... and moments later, I 
>>> end up with something like:
>>> U 63.64.65.66:5060 -> 63.64.65.66:5060ACK sip:201 at 63.64.65.66:5060 
>>> SIP/2.0.Record-Route:
>>>   
>> Your ACK is going to the wrong port.  If you say SEMS is on 5090 then 
>> the remote end is not sending the ACK to the correct port.  You will 
>> need to take a look at the whole SIP message exchange to see if its 
>> your fault or the other providers fault.  
>>
> Just a clarification.  When I say it is sending the ACK to the wrong 
> port I am refering to this part of the message:  ACK 
> sip:201 at 63.64.65.66:5060 (which is build from Contact Header details).
> ..not this part:  U 63.64.65.66:5060 -> 63.64.65.66:5060
>
>>  
>>
>>> So what do you think? Any ideas on what might cause different 
>>> routing behaviour for locally-registered and non-locally-registered 
>>> UAs? Would taking the approach of tossing all the rewrites into a 
>>> separate routing block and calling it from the ACK, CANCEL, BYE, and 
>>> INVITE blocks be just heading down the wrong path?
>>>
>>>
>>>
>>>   
>> Yes, and again a complete comparison of SIP messages in both test 
>> cases will reveal why.  Look at the contact header throughout all 
>> messages to see what happens.  The non-locally-registered UAs are 
>> sending the ACK to the wrong port.
>>
>> Andres
>> http://www.telesip.net
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>>  
>>