[SR-Users] ACK and BYE are forwarded statelessly (failed to parse Route HF)

[Daniel-Constantin Mierla]

Hello,

the caller side builds the ack inccorectly.

The Contact in 200ok for INVITE is:

Contact: <sip:10004 at 10.10.11.232:5060>.

But the ACK coming to the server has:

ACK sip:10004 at 44.44.44.148:5060 SIP/2.0.

I see that there is proxy between the caller and the server, it could be
the one doing some wrong mangling of Contact in 200ok.

Do you control the sip proxy that adds the header:

Record-Route: <sip:194.213.29.92;lr=on;ftag=as62247c45>.

Cheers,
Daniel

On 29/09/15 15:42, Miroslav Dunaev wrote:
> Hello everyone,
> I have a setup where ​kamailio acts as UAC to a SIP provider.
> Kamailio is also configured to pass all incoming calls to an Asterisk.
> Here is a diagram:
>
> Phone<-->Asterisk(10.10.11.232)<--->(PRIV:10.10.11.238)Kamailio(PUB:44.44.44.148)<--->(194.213.29.92)SIP-provider.
>
> When a call comes in from the SIP-provider, it gets all the way to the
> phone.
> But when the SIP-provider sends BYE or ACK (during hungup event or
>  200OK/SDP asterisk response.).
> I get this errors in my kamailio log:
>
>
>  siputils [checks.c:100]: has_totag(): totag found
> <core> [parser/parse_rr.c:49]: do_parse_rr_body(): parse_rr_body(): No
> body for record-route
> rr [loose.c:106]: find_first_route(): failed to parse Route HF
> rr [loose.c:929]: loose_route(): There is no Route HF
> tm [t_lookup.c:648]: t_lookup_request(): DEBUG: t_lookup_request: no
> transaction found
> tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=1
> global id=0 T start=0xffffffffffffffff
> tm [t_lookup.c:466]: t_lookup_request(): t_lookup_request: start
> searching: hash=10101, isACK=1
> tm [t_lookup.c:424]: matching_3261(): DEBUG: RFC3261 transaction
> matching failed
> .....
> ....
> ....
> siputils [checks.c:100]: has_totag(): totag found
> tm [t_lookup.c:1312]: t_newtran(): DEBUG: t_newtran: msg id=2 , global
> msg id=1 , T on entrance=0xffffffffffffffff
> tm [t_lookup.c:466]: t_lookup_request(): t_lookup_request: start
> searching: hash=10101, isACK=1
> tm [t_lookup.c:424]: matching_3261(): DEBUG: RFC3261 transaction
> matching failed
> tm [t_lookup.c:648]: t_lookup_request(): DEBUG: t_lookup_request: no
> transaction found
> tm [t_funcs.c:279]: t_relay_to(): SER: forwarding ACK  statelessly
>
> here is the link to: kamailio.cfg, ngrep -i any capture, debug_level6
> log: http://labmir.com/kamailio/
>
>
> Looking at the SIP ACK that comes from SIP provider I can see that
> they use strict routing.
> (i.e. TO field is set to kamailio's  public IP that is next hop to them). 
> Maybe I am wrong to judge that its not loose routing just because of
> the TO field.
>
> Anyways, because of (failed to parse Route HF) error, ACKs and BYEs
> are forwarded by kamailio statelessly, as a result kamailio uses wrong
> interface to forward them (SIP_dailog.txt line:233) and therefore
> asterisk never sees ACKs or BYEs.
>
> How can I make kamailio recognize ACKs and BYEs belonging to a dialog
> and pass them statefully through the right interface?
>
> It is worth to mention that I use exactly the same config with a
> different SIP-provider (which is peered to our PUB IP not registered
> through UAC like in this case) and it works flawlessly.
>
> Thank you,
> Mir
>
>
>
>
> _______________________________________________
> 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

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150930/74165856/attachment.html>