28 Jun
2007
28 Jun
'07
9:42 p.m.
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@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:
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@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(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
> 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@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.