Hi Daniel,
Unfortunately, I cannot disclose the vendor of the second proxy; however I will
say that it is an aged platform (originally written back in 2005; and has
quirks/bugs/oddities of it's own), and is in the process of being replaced with
kamailio -- we have to do a staggered roll-out; slowly replacing the old
platform with kamailio.
The proxy itself is on it's own dedicated box, and when triggering this call
scenario, both boxes are seeing this traffic. As with my OP; I was able to
suppress this via a routing logic change -- essentially by keeping track of how
many 100 provisional replies and limiting it; however I was wondering if there
is a parameter that can be adjusted change this behavior -- as an example,
allow a few CANCELs to be transmitted; but after a certain amount; just stop
retransmitting, and treat it like a failed route.
Thank you.
------- Original Message -------
On Wednesday, August 23rd, 2023 at 12:35 PM, Daniel-Constantin Mierla
<[email protected]> wrote:
> Hello,
>
> that's really strange to have 14000+ of CANCEL/100trying ... is it some
> container-based infrastructure there? Sometimes capturing the traffic on
> containers shows strange results ...
>
> What is the second proxy? I don't recall by heart the specs, but I think if
> next hop replies with 1xx after cancelling the leg, the current node has to
> send again the CANCEL to be ensure the previous one was not lost causing the
> next hop to resend the 1xx...
>
> Cheers,
> Daniel
>
> On 23.08.23 15:53, James Lipski wrote:
>
>> Hello,
>>
>> I've already suppressed this via routing logic, however I was wondering if
>> there is a dedicated parameter that handles this. I'm currently running
>> version 5.6.4.
>>
>> Scenario:
>> UA-1 registered towards kamailio, calls UA-2 which is registered towards a
>> different platform (non kamailio); so there are 2 proxys involved. kamailio
>> is set to fork the call to voicemail if there is either no response
>> completely from the other end, or the call goes unanswered.
>>
>> So the initial leg is:
>>
>> UA-1 <-----> kamailio <-----> second proxy <-----> UA-2
>>
>> Issue:
>> I'm trying to catch a case where the second proxy does issue a "100 Trying"
>> for the initial INVITE; and then timesout. The call does fork to voicemail;
>> however 14000+ SIP packets are generated between kamailio and the second
>> proxy of CANCEL and "100 Trying" (the 100 Trying has a CSeq for INVITE
>> still).
>>
>> Is there a way to suppress the amount of CANCELs that is transmitted in this
>> situation?
>>
>> I'm using the following as my "tm" parameters:
>> modparam("tm", "failure_reply_mode", 3)
>> modparam("tm", "fr_timer", 30000)
>> modparam("tm", "fr_inv_timer", 300000)
>> modparam("tm", "auto_inv_100_reason", "Trying")
>>
>> Thanks.
>>
>> Example SIP trace:
>> (UA-1 --> kamailio)
>> 72.255.255.255 --> 10.64.52.110
>>
>> INVITE sip:[email protected] SIP/2.0
>> v: SIP/2.0/UDP 10.0.0.102:51519;branch=z9hG4bK-xfelmyyjzne5;rport
>> f: <sip:[email protected]>;tag=i4mlq4jr0y
>> t: <sip:[email protected]>
>> i: 95c3e4642670-rx28v46dte4p
>> CSeq: 1 INVITE
>> Max-Forwards: 70
>> User-Agent: snomD785/10.1.152.12
>> m:
>> [<sip:[email protected]:51519;line=6dv00d6r>](mailto:sip:[email protected]:51519;line=6dv00d6r);reg-id=1
>> Accept: application/sdp
>> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK,
>> MESSAGE, INFO, UPDATE
>> Allow-Events: talk, hold, refer, call-info
>> Supported: timer, replaces, from-change
>> Session-Expires: 3600
>> Min-SE: 90
>> Proxy-Authorization: Digest
>> username="133",realm="sip-example.com",nonce="ZOTEBGTkwtiM22ZE8IJsn/esiW3CZrt0"[,uri="sip:[email protected]](mailto:,uri=)",response="fb44b4fe0f8fb17de13f043cf1248e14",algorithm=MD5
>> c: application/sdp
>> l: 309
>>
>> v=0
>> o=root 481174289 481174289 IN IP4 10.0.0.102
>> s=call
>> c=IN IP4 10.0.0.102
>> t=0 0
>> m=audio 50864 RTP/AVP 9 0 8 18 101
>> a=rtpmap:9 G722/8000
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:18 G729/8000
>> a=fmtp:18 annexb=no
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>> a=ptime:20
>> a=sendrecv
>>
>> --------------------------------------------
>> (UA-1 <-- kamailio)
>> 72.255.255.255 <-- 10.64.52.110
>>
>> SIP/2.0 100 Trying
>> v: SIP/2.0/UDP
>> 10.0.0.102:51519;branch=z9hG4bK-xfelmyyjzne5;rport=51519;received=72.255.255.255
>> f: <sip:[email protected]>;tag=i4mlq4jr0y
>> t: <sip:[email protected]>
>> i: 95c3e4642670-rx28v46dte4p
>> CSeq: 1 INVITE
>> Content-Length: 0
>>
>> --------------------------------------------
>> (kamailio --> second proxy)
>> 10.64.52.110 --> 10.64.52.100
>>
>> INVITE sip:second-proxy-example.com:5066;ua=43a58ecca39c9c8f37515e55b5b37ed7
>> SIP/2.0
>> Via: SIP/2.0/UDP
>> 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0
>> f: <sip:[email protected]>;tag=i4mlq4jr0y
>> t: <sip:[email protected]?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>
>> i: 95c3e4642670-rx28v46dte4p
>> CSeq: 1 INVITE
>> Max-Forwards: 15
>> Accept: application/sdp
>> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK,
>> MESSAGE, INFO, UPDATE
>> Allow-Events: talk, hold, refer, call-info
>> Supported: timer, replaces, from-change
>> Session-Expires: 3600
>> Min-SE: 90
>> c: application/sdp
>> l: 313
>> Contact: <sip:[email protected];ccr=btpsh-64e387e0-ee528-2>
>>
>> v=0
>> o=root 481174289 481174289 IN IP4 10.64.52.111
>> s=call
>> c=IN IP4 10.64.52.111
>> t=0 0
>> m=audio 34084 RTP/AVP 9 0 8 18 101
>> a=rtpmap:9 G722/8000
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:18 G729/8000
>> a=fmtp:18 annexb=no
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>> a=ptime:20
>> a=sendrecv
>>
>> --------------------------------------------
>> (kamailio <-- second proxy)
>> 10.64.52.110 <-- 10.64.52.100
>>
>> SIP/2.0 100 Trying
>> v: SIP/2.0/UDP
>> 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0
>> f: <sip:[email protected]>;tag=i4mlq4jr0y
>> t: <sip:[email protected]?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>
>> i: 95c3e4642670-rx28v46dte4p
>> CSeq: 1 INVITE
>> l: 0
>>
>> --------------------------------------------
>> After 10 seconds of no further response from second proxy, call is forked to
>> voicemail
>> (kamailio --> voicemail)
>> 10.64.52.110 --> 10.64.56.10
>>
>> INVITE sip:[email protected] SIP/2.0
>> Via: SIP/2.0/UDP
>> 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.1
>> f: <sip:[email protected]>;tag=i4mlq4jr0y
>> t: <sip:[email protected]?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>
>> i: 95c3e4642670-rx28v46dte4p
>> CSeq: 1 INVITE
>> Max-Forwards: 15
>> Accept: application/sdp
>> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK,
>> MESSAGE, INFO, UPDATE
>> Allow-Events: talk, hold, refer, call-info
>> Supported: timer, replaces, from-change
>> Session-Expires: 3600
>> Min-SE: 90
>> c: application/sdp
>> l: 313
>> Contact: <sip:[email protected];ccr=btpsh-64e387e0-ee533-3>
>>
>> v=0
>> o=root 481174289 481174289 IN IP4 10.64.52.111
>> s=call
>> c=IN IP4 10.64.52.111
>> t=0 0
>> m=audio 38722 RTP/AVP 9 0 8 18 101
>> a=rtpmap:9 G722/8000
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:18 G729/8000
>> a=fmtp:18 annexb=no
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>> a=ptime:20
>> a=sendrecv
>>
>> --------------------------------------------
>> At roughly the same time, CANCEL is issued towards the second proxy
>> (kamailio --> second proxy)
>> 10.64.52.110 --> 10.64.52.100
>>
>> CANCEL sip:second-proxy-example.com:5066;ua=43a58ecca39c9c8f37515e55b5b37ed7
>> SIP/2.0
>> Via: SIP/2.0/UDP
>> 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0
>> f: <sip:[email protected]>;tag=i4mlq4jr0y
>> t: <sip:[email protected]>
>> i: 95c3e4642670-rx28v46dte4p
>> CSeq: 1 CANCEL
>> Max-Forwards: 15
>> l: 0
>>
>> --------------------------------------------
>> (kamailio <-- voicemail)
>> 10.64.52.110 <-- 10.64.56.10
>>
>> SIP/2.0 200 Ok
>> Via: SIP/2.0/UDP
>> 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.1
>> From: <sip:[email protected]>;tag=i4mlq4jr0y
>> To:
>> <sip:[email protected]?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>;tag=vzx5x3mlbd
>> Call-ID: 95c3e4642670-rx28v46dte4p
>> CSeq: 1 INVITE
>> Contact:
>> [<sip:[email protected]:5078>](mailto:sip:[email protected]:5078)
>> Require: timer
>> Session-Expires: 3600;refresher=uac
>> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK,
>> MESSAGE, INFO
>> Supported: timer, 100rel, replaces
>> Content-Type: application/sdp
>> Content-Length: 264
>>
>> v=0
>> o=root 1084843702 1084843703 IN IP4 10.64.56.10
>> s=call
>> c=IN IP4 10.64.56.10
>> t=0 0
>> m=audio 31908 RTP/AVP 0 101
>> a=rtpmap:0 pcmu/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>> a=ptime:20
>> a=alt:1 0.9 : user 9kksj== 10.64.56.10 31908
>> a=sendrecv
>>
>> --------------------------------------------
>> (UA-1 <-- kamailio)
>> 72.255.255.255 <-- 10.64.52.110
>>
>> SIP/2.0 200 Ok
>> From: <sip:[email protected]>;tag=i4mlq4jr0y
>> To:
>> <sip:[email protected]?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>;tag=vzx5x3mlbd
>> Call-ID: 95c3e4642670-rx28v46dte4p
>> CSeq: 1 INVITE
>> Require: timer
>> Session-Expires: 3600;refresher=uac
>> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK,
>> MESSAGE, INFO
>> Supported: timer, 100rel, replaces
>> Content-Type: application/sdp
>> Content-Length: 270
>> Via: SIP/2.0/UDP
>> 10.0.0.102:51519;received=72.255.255.255;branch=z9hG4bK-xfelmyyjzne5;rport=51519
>> Contact: <sip:[email protected];ccr=atpsh-64e387e0-ee533-3>
>>
>> v=0
>> o=root 1084843702 1084843703 IN IP4 10.64.52.110
>> s=call
>> c=IN IP4 10.64.52.110
>> t=0 0
>> m=audio 33552 RTP/AVP 0 101
>> a=rtpmap:0 pcmu/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>> a=ptime:20
>> a=alt:1 0.9 : user 9kksj== 10.64.56.10 31908
>> a=sendrecv
>>
>> ===============================================
>> These next 2 SIP packets repeat, generating 14000+ CANCEL <--> 100 Trying
>> transactions between kamailio, and the second proxy.
>> (kamailio --> second proxy)
>> 10.64.52.110 --> 10.64.52.100
>>
>> CANCEL sip:second-proxy-example.com:5066;ua=43a58ecca39c9c8f37515e55b5b37ed7
>> SIP/2.0
>> Via: SIP/2.0/UDP
>> 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0
>> f: <sip:[email protected]>;tag=i4mlq4jr0y
>> t: <sip:[email protected]>
>> i: 95c3e4642670-rx28v46dte4p
>> CSeq: 1 CANCEL
>> Max-Forwards: 15
>> l: 0
>>
>> --------------------------------------------
>> (kamailio <-- second proxy)
>> 10.64.52.110 <-- 10.64.52.100
>>
>> SIP/2.0 100 Trying
>> v: SIP/2.0/UDP
>> 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0
>> f: <sip:[email protected]>;tag=i4mlq4jr0y
>> t: <sip:[email protected]?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>
>> i: 95c3e4642670-rx28v46dte4p
>> CSeq: 1 INVITE
>> l: 0
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to
>> [email protected]
>> Important: keep the mailing list in the recipients, do not reply only to the
>> sender!
>> Edit mailing list options or unsubscribe:
>
> --
> Daniel-Constantin Mierla (@ asipto.com)
> twitter.com/miconda -- linkedin.com/in/miconda
> Kamailio Consultancy - Training Services -- asipto.com
> Kamailio World Conference - kamailioworld.com__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
