[SR-Users] ACK to 486 is not being proxied
Daniel-Constantin Mierla
miconda at gmail.com
Fri May 20 15:55:18 CEST 2011
Please do not write private emails, keep the mailing list cc-ed.
Can you get the output of:
ngrep -d any -qt -W byline port 5040
on kamailio server for such a call? Include all messages, since you may
miss something in your filtering (like you did below), of course you can
mask the ip addresses.
Also, be sure you do t_relay() to forward the invite from kamailio on.
Cheers,
Daniel
On 5/20/11 3:47 PM, Carl Wagner wrote:
> Daniel,
>
> With a non-2xx reply being hop-by-hop, shouldn't Kamailio receive the
> 486, send the ACK to the sender, and then proxy the 486?
>
> I am not seeing the 486 message in the Kamailio log so I assume that
> it automatically handles it without hitting the kamailio.cfg script?
> Or do I need to set up a failure_route to catch the 486 and send the
> ACK there?
>
> Please see the log below.
>
> Thanks,
> Carl
>
>
>
> # Asterisk to Kamailio
> U 2011/05/19 14:13:01.467157 3.4.5.167:5060 -> 3.4.5.164:5060
> INVITE sip:+13031112222 at 3.4.5.164 SIP/2.0.
> Via: SIP/2.0/UDP 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport.
> From: "+13032223333" <sip:+13032223333 at 3.4.5.167>;tag=as1f559f5a.
> To: <sip:+13031112222 at 3.4.5.164>.
> Contact: <sip:+13032223333 at 3.4.5.167>.
> Call-ID: 37ef92a26c31a7f85958ae996d49a872 at 3.4.5.167.
> CSeq: 102 INVITE.
> User-Agent: Asterisk.
> Max-Forwards: 70.
> Date: Thu, 19 May 2011 20:13:01 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
> Supported: replaces.
> Content-Type: application/sdp.
> Content-Length: 238.
> .
> v=0.
> o=root 27806 27806 IN IP4 3.4.5.167.
> s=session.
> c=IN IP4 3.4.5.167.
> t=0 0.
> m=audio 13424 RTP/AVP 0 101.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=silenceSupp:off - - - -.
> a=ptime:20.
> a=sendrecv.
>
> # Kamailio to provider
> U 2011/05/19 14:13:01.468627 3.4.5.164:5060 -> 2.3.4.40:5060
> INVITE sip:+13031112222 at 2.3.4.40:5060 SIP/2.0.
> Record-Route: <sip:3.4.5.164;lr=on>.
> Via: SIP/2.0/UDP 3.4.5.164;branch=0.
> Via: SIP/2.0/UDP 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport=5060.
> From: "+13032223333" <sip:+13032223333 at 3.4.5.167>;tag=as1f559f5a.
> To: <sip:+13031112222 at 2.3.4.40:5060>.
> Contact: <sip:+13032223333 at 3.4.5.167>.
> Call-ID: 37ef92a26c31a7f85958ae996d49a872 at 3.4.5.167.
> CSeq: 102 INVITE.
> User-Agent: Asterisk.
> Max-Forwards: 69.
> Date: Thu, 19 May 2011 20:13:01 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
> Supported: replaces.
> Content-Type: application/sdp.
> Content-Length: 238.
> .
> v=0.
> o=root 27806 27806 IN IP4 3.4.5.167.
> s=session.
> c=IN IP4 3.4.5.167.
> t=0 0.
> m=audio 13424 RTP/AVP 0 101.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=silenceSupp:off - - - -.
> a=ptime:20.
> a=sendrecv.
>
>
> U 2011/05/19 14:13:01.511775 2.3.4.40:37897 -> 3.4.5.164:5060
> SIP/2.0 100 Trying.
> Via: SIP/2.0/UDP 3.4.5.164;branch=0,SIP/2.0/UDP
> 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport=5060.
> From: "+13032223333" <sip:+13032223333 at 3.4.5.167>;tag=as1f559f5a.
> To: <sip:+13031112222 at 2.3.4.40:5060>.
> Call-ID: 37ef92a26c31a7f85958ae996d49a872 at 3.4.5.167.
> CSeq: 102 INVITE.
> Content-Length: 0.
> .
>
>
> U 2011/05/19 14:13:01.513162 3.4.5.164:5060 -> 3.4.5.167:5060
> SIP/2.0 100 Trying.
> Via: SIP/2.0/UDP 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport=5060.
> From: "+13032223333" <sip:+13032223333 at 3.4.5.167>;tag=as1f559f5a.
> To: <sip:+13031112222 at 2.3.4.40:5060>.
> Call-ID: 37ef92a26c31a7f85958ae996d49a872 at 3.4.5.167.
> CSeq: 102 INVITE.
> Content-Length: 0.
> .
>
> # provider says they are busy
> U 2011/05/19 14:13:03.239462 2.3.4.40:37897 -> 3.4.5.164:5060
> SIP/2.0 486 Busy Here.
> Via: SIP/2.0/UDP 3.4.5.164;branch=0,SIP/2.0/UDP
> 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport=5060.
> Record-Route: <sip:3.4.5.164;lr=on>.
> From: "+13032223333" <sip:+13032223333 at 3.4.5.167>;tag=as1f559f5a.
> To: <sip:+13031112222 at 2.3.4.40:5060>;tag=VPST506071629352.
> Call-ID: 37ef92a26c31a7f85958ae996d49a872 at 3.4.5.167.
> CSeq: 102 INVITE.
> Contact: <sip:+13031112222 at 2.3.4.40:5060;transport=udp>.
> Content-Length: 0.
> .
>
> #
> # should Kamailio send the ACK here?
> #
>
> # Kamailio proxies the 486 to Asterisk
> U 2011/05/19 14:13:03.240820 3.4.5.164:5060 -> 3.4.5.167:5060
> SIP/2.0 486 Busy Here.
> Via: SIP/2.0/UDP 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport=5060.
> Record-Route: <sip:3.4.5.164;lr=on>.
> From: "+13032223333" <sip:+13032223333 at 3.4.5.167>;tag=as1f559f5a.
> To: <sip:+13031112222 at 2.3.4.40:5060>;tag=VPST506071629352.
> Call-ID: 37ef92a26c31a7f85958ae996d49a872 at 3.4.5.167.
> CSeq: 102 INVITE.
> Contact: <sip:+13031112222 at 2.3.4.40:5060;transport=udp>.
> Content-Length: 0.
> .
>
>
> # ACK from Asterisk - should be swallowed by Kamailio
> U 2011/05/19 14:13:03.243870 3.4.5.167:5060 -> 3.4.5.164:5060
> ACK sip:+13031112222 at 3.4.5.164 SIP/2.0.
> Via: SIP/2.0/UDP 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport.
> From: "+13032223333" <sip:+13032223333 at 3.4.5.167>;tag=as1f559f5a.
> To: <sip:+13031112222 at 3.4.5.164>;tag=VPST506071629352.
> Contact: <sip:+13032223333 at 3.4.5.167>.
> Call-ID: 37ef92a26c31a7f85958ae996d49a872 at 3.4.5.167.
> CSeq: 102 ACK.
> User-Agent: Asterisk.
> Max-Forwards: 70.
> Content-Length: 0.
> .
>
>
> ==== a bunch of retransmitted 486's chopped =============
>
>
>
>
>
>
>
> On 05/19/2011 02:30 AM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> the ACK for non-2xx replies is hop-by-hop, meaning that kamailio will
>> generate one when the reply is received, will send back the reply and
>> when the ack comes from upstream, it will absorb it.
>>
>> In this case it seems that ack is not matching any invite transaction
>> and thus is not known where to send it.
>>
>> Can you send the invite, reply and the ack requests taken with ngrep
>> for such case? Maybe is something broken in the content of the message.
>>
>> Cheers,
>> Daniel
>>
>> On 5/18/11 11:23 PM, Carl Wagner wrote:
>>> Hi,
>>>
>>> I have Kamailio set up to act as a proxy and load balancer. Most
>>> things are working correctly but for some reason I can't get
>>> Kamailio to proxy an ACK to a 486 Busy.
>>> I assume that it is something wrong that I have done in the
>>> kamailio.cfg file but I am not seeing it.
>>>
>>> Does the t_check_trans() return false because the call state is Busy?
>>>
>>> Please let me know if you need other logs or information.
>>>
>>> Thanks in advance,
>>> Carl
>>>
>>>
>>>
>>> ================== Call flow: (from ngrep) ======================
>>>
>>> Asterisk Kamailio Provider
>>> INVITE--------->
>>> INVITE--------->
>>> <----------100 Trying
>>> <---------100 Trying
>>> <----------486 Busy
>>> <---------486 Busy
>>> ACK------------->
>>> ====== Kamailio does not proxy the ACK here =======
>>> <----------486 Busy
>>> <---------486 Busy
>>> ACK------------->
>>> <----------486 Busy
>>> <---------486 Busy
>>>
>>>
>>> === kamailio.cfg snippet
>>> ...
>>> route
>>> {
>>> route(REQINIT); # remove malformed messages
>>>
>>> # handle requests within SIP dialogs
>>> route(WITHINDLG);
>>> ...
>>> }
>>>
>>> ###################################################################
>>> # Handle requests within SIP dialogs (request has a TO: Tag)
>>> route[WITHINDLG]
>>> {
>>> if (has_totag())
>>> {
>>> xlog("L_INFO", " WITHINDLG: SIP Request: [$rm] ruri=[$ru] (from
>>> [$fu] to [$tu], Call-ID=[$ci], CSeq=[$cs])\n");
>>> if (loose_route())
>>> {
>>> ...
>>> }
>>> else # not loose_route
>>> {
>>> if ( is_method("ACK") )
>>> {
>>> if ( t_check_trans() ) # see if a message is related to
>>> a transaction
>>> {
>>> ...
>>> }
>>> else
>>> {
>>> # ACK without matching transaction ... ignore and
>>> discard
>>> xlog("L_INFO", " WITHINDLG: has TO: tag AND loose_route is NOT true
>>> and is_method = ACK and t_check_trans=FALSE\n");
>>>
>>> # not forwarded here!!! Tried both t_relay and forward.
>>> # $var(a) = t_relay();
>>> $var(a) = forward();
>>> xlog ("L_INFO", " WITHINDLG: (ReturnCode = [$var(a)]
>>> exiting)\n");
>>>
>>> exit;
>>> }
>>> }
>>> sl_send_reply("404","Not here");
>>> }
>>> exit;
>>> }
>>> }
>>>
>>> ============= End of kamailio.cfg ================
>>>
>>>
>>> ============= /var/log/messages - snippit of the message ==========
>>>
>>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>:
>>> ======== processing new message
>>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>:
>>> MAIN: SIP Request: [ACK] ruri=[sip:+13031112222 at 2.3.4.5] (from
>>> [sip:+13031112222 at 3.4.5.6] to [sip:+13031112222 at 2.3.4.5],
>>> Call-ID=[21a30b9168e0a8c963d47ca1361cef77 at 3.4.5.6]) CSeq=[102]
>>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>:
>>> WITHINDLG: SIP Request: [ACK] ruri=[sip:+13031112222 at 2.3.4.5] (from
>>> [sip:+13031112222 at 3.4.5.6] to [sip:+13031112222 at 2.3.4.5],
>>> Call-ID=[21a30b9168e0a8c963d47ca1361cef77 at 3.4.5.6], CSeq=[102])
>>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>:
>>> WITHINDLG: has TO: tag
>>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>:
>>> WITHINDLG: has TO: tag AND loose_route is NOT true and is_method =
>>> ACK and t_check_trans=FALSE
>>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>:
>>> WITHINDLG: the ACK to a 486 was not being processed so I am
>>> adding t_relay here
>>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>:
>>> WITHINDLG: (ReturnCode = [1] exiting)
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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://www.asipto.com
>
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110520/3b3ec5e9/attachment-0001.htm>
More information about the sr-users
mailing list