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
<miconda(a)gmail.com> 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:131@sip-example.com SIP/2.0
v: SIP/2.0/UDP 10.0.0.102:51519;branch=z9hG4bK-xfelmyyjzne5;rport
f: <sip:133@sip-example.com>;tag=i4mlq4jr0y
t: <sip:131@sip-example.com>
i: 95c3e4642670-rx28v46dte4p
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.152.12
m:
[<sip:133@10.0.0.102:51519;line=6dv00d6r>](mailto:sip:133@10.0.0.102: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:131@sip-example.com](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:133@sip-example.com>;tag=i4mlq4jr0y
t: <sip:131@sip-example.com>
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:133@sip-example.com>;tag=i4mlq4jr0y
t: <sip:131@sip-example.com?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:leg_1@sip-example.com;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:133@sip-example.com>;tag=i4mlq4jr0y
t: <sip:131@sip-example.com?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:voicemail@voicemail-example.com SIP/2.0
Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.1
f: <sip:133@sip-example.com>;tag=i4mlq4jr0y
t: <sip:131@sip-example.com?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:leg_1@sip-example.com;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:133@sip-example.com>;tag=i4mlq4jr0y
t: <sip:131@sip-example.com>
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:133@sip-example.com>;tag=i4mlq4jr0y
To:
<sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>;tag=vzx5x3mlbd
Call-ID: 95c3e4642670-rx28v46dte4p
CSeq: 1 INVITE
Contact: [<sip:voicemail@10.64.56.10:5078>](mailto:sip:voicemail@10.64.56.10: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:133@sip-example.com>;tag=i4mlq4jr0y
To:
<sip:131@sip-example.com?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:leg_2@sip-example.com;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:133@sip-example.com>;tag=i4mlq4jr0y
t: <sip:131@sip-example.com>
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:133@sip-example.com>;tag=i4mlq4jr0y
t: <sip:131@sip-example.com?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
sr-users-leave(a)lists.kamailio.org
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