26 Sep
2023
26 Sep
'23
11:50 p.m.
Hello,
Is there a way to change the transaction order when a failure fork occurs -- to explain,
endpoint 1 calls endpoint 2. Call towards endpoint 2 goes unanswered, and so the call
forks to voicemail, I see that an INVITE is sent towards my voicemail server first,
followed by a CANCEL towards the endpoint; can I send the CANCEL first to the endpoint and
then INVITE towards my voicemail server. I'm essentially using the bundled/sample
configurations for testing.
Thank you.
27 Sep
27 Sep
4:12 a.m.
Hi James,
The difference you are describing is between serial and parallel forking. You clearly want
the former. There are a variety of ways to achieve that, and the answer will depend on the
code path taken to route to your voicemail server.
-- Alex
On Sep 26, 2023, at 5:50 PM, James Lipski via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Hello,
Is there a way to change the transaction order when a failure fork occurs -- to explain,
endpoint 1 calls endpoint 2. Call towards endpoint 2 goes unanswered, and so the call
forks to voicemail, I see that an INVITE is sent towards my voicemail server first,
followed by a CANCEL towards the endpoint; can I send the CANCEL first to the endpoint and
then INVITE towards my voicemail server. I'm essentially using the bundled/sample
configurations for testing.
Thank you.__________________________________________________________
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:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
8:04 a.m.
Hello,
default kamailio.cfg has a skeleton for doing serial forking to a
voicemail server. Follow the token WITH_VOICEMAIL to discover the
related snippets -- this can be a starting point to implement it in your
config.
Cheers,
Daniel
On 27.09.23 04:12, Alex Balashov via sr-users wrote:
Hi James,
The difference you are describing is between serial and parallel forking. You clearly
want the former. There are a variety of ways to achieve that, and the answer will depend
on the code path taken to route to your voicemail server.
-- Alex
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy - Training Services -- asipto.com
Kamailio World Conference - kamailioworld.com
On Sep 26, 2023, at 5:50 PM, James Lipski via
sr-users <sr-users(a)lists.kamailio.org> wrote:
Hello,
Is there a way to change the transaction order when a failure fork occurs -- to explain,
endpoint 1 calls endpoint 2. Call towards endpoint 2 goes unanswered, and so the call
forks to voicemail, I see that an INVITE is sent towards my voicemail server first,
followed by a CANCEL towards the endpoint; can I send the CANCEL first to the endpoint and
then INVITE towards my voicemail server. I'm essentially using the bundled/sample
configurations for testing.
Thank you.__________________________________________________________
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:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
__________________________________________________________
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:
3:43 p.m.
Hello,
Thanks for the reply. I'm using the bundled/skeleton configurations just to test with
a few modifications (adding the actual voicemail server) however even with the skeleton
configurations, when the call goes unanswered, and the call forks to voicemail, the INVITE
packet is sent first, followed by the CANCEL to endpoint 2. The following is a SIP trace
of what I'm seeing:
10.0.0.117 -- Endpoint 1
10.0.0.177 -- Kamailio
10.0.0.110 -- Endpoint 2
10.0.0.26 -- Voicemail
2023/09/27 09:27:06.326167 10.0.0.117:42414 -> 10.0.0.177:5060
INVITE sip:10000008@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport
f: <sip:10000006@10.0.0.177>;tag=rsxulncekf
t: <sip:10000008@10.0.0.177>
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:42414;line=aoec88fl>;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="10000006",realm="10.0.0.177",nonce="ZRQu1mUULaq2rH8lPjaCtARPy4Wa7KfQ",uri="sip:10000008@10.0.0.177",response="a2cf69a439f25e97b238510377cc4900",algorithm=MD5
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.329198 10.0.0.177:5060 -> 10.0.0.117:42414
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP
10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414;received=10.0.0.117
f: <sip:10000006@10.0.0.177>;tag=rsxulncekf
t: <sip:10000008@10.0.0.177>
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Content-Length: 0
2023/09/27 09:27:06.329914 10.0.0.177:5060 -> 10.0.0.110:5063
INVITE sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes>
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414
f: <sip:10000006@10.0.0.177>;tag=rsxulncekf
t: <sip:10000008@10.0.0.177>
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1>;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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.385247 10.0.0.110:5063 -> 10.0.0.177:5060
SIP/2.0 100 Trying
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: <sip:10000006@10.0.0.177>;tag=rsxulncekf
Record-Route: <sip:10.0.0.177;lr;nat=yes>
t: <sip:10000008@10.0.0.177>;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;received=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414
Server: OBIHAI/OBi200-3.2.1.5757
2023/09/27 09:27:06.461036 10.0.0.110:5063 -> 10.0.0.177:5060
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: <sip:10000006@10.0.0.177>;tag=rsxulncekf
Record-Route: <sip:10.0.0.177;lr;nat=yes>
t: <sip:10000008@10.0.0.177>;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;received=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414
Server: OBIHAI/OBi200-3.2.1.5757
m: <sip:10000008@10.0.0.110:5063>
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO,
UPDATE
2023/09/27 09:27:06.462644 10.0.0.177:5060 -> 10.0.0.117:42414
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: <sip:10000006@10.0.0.177>;tag=rsxulncekf
Record-Route: <sip:10.0.0.177;lr;nat=yes>
t: <sip:10000008@10.0.0.177>;tag=SP49be74061f6fb65ae
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414
Server: OBIHAI/OBi200-3.2.1.5757
m: <sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1>
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO,
UPDATE
2023/09/27 09:27:51.447756 10.0.0.177:5060 -> 10.0.0.26:7066
INVITE sip:10000008@10.0.0.26:7066 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes>
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414
f: <sip:10000006@10.0.0.177>;tag=rsxulncekf
t: <sip:10000008@10.0.0.177>
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1>;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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:51.466497 10.0.0.177:5060 -> 10.0.0.110:5063
CANCEL sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
f: <sip:10000006@10.0.0.177>;tag=rsxulncekf
t: <sip:10000008@10.0.0.177>
i: a62d14656998-uhh0lmce49oh
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/27 09:27:51.466503 10.0.0.177:5060 -> 10.0.0.26:7066
ACK sip:10000008@10.0.0.26:7066 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
f: <sip:10000006@10.0.0.177>;tag=rsxulncekf
t: <sip:10000008@10.0.0.177>;tag=2faa70b9-a47d-42d0-87fc-779e397ebc7e
i: a62d14656998-uhh0lmce49oh
CSeq: 2 ACK
Max-Forwards: 69
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 2:04 AM, Daniel-Constantin Mierla via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Hello,
default kamailio.cfg has a skeleton for doing serial forking to a
voicemail server. Follow the token WITH_VOICEMAIL to discover the
related snippets -- this can be a starting point to implement it in your
config.
Cheers,
Daniel
On 27.09.23 04:12, Alex Balashov via sr-users wrote:
Hi James,
The difference you are describing is between serial and parallel forking. You clearly
want the former. There are a variety of ways to achieve that, and the answer will depend
on the code path taken to route to your voicemail server.
-- Alex
--
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 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: On Sep 26, 2023, at 5:50 PM, James Lipski via
sr-users sr-users(a)lists.kamailio.org wrote:
Hello,
Is there a way to change the transaction order when a failure fork occurs -- to explain,
endpoint 1 calls endpoint 2. Call towards endpoint 2 goes unanswered, and so the call
forks to voicemail, I see that an INVITE is sent towards my voicemail server first,
followed by a CANCEL towards the endpoint; can I send the CANCEL first to the endpoint and
then INVITE towards my voicemail server. I'm essentially using the bundled/sample
configurations for testing.
Thank you.__________________________________________________________
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:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
__________________________________________________________
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:
28 Sep
28 Sep
10:08 p.m.
Hello,
As with my previous update, I'm using the skeleton configurations (with minor changes,
such as defining an external voicemail destination) just for testing purposes. With the
skeleton configurations, I'm still seeing that the INVITE packet to the voicemail
server sent first, and then the CANCEL to the second endpoint (please see SIP trace
below). In this call example the second endpoint is a PBX, and is configured to route
unanswered calls towards it's own local voicemail system. Is there a way to switch the
behaviour so that the CANCEL packet towards endpoint 2 is sent FIRST; and then the INVITE
to the voicemail system second? Thank you.
10.0.0.117 --- snom (endpoint 1)
10.0.0.177 --- kamailio
10.0.0.188 --- PBX (endpoint 2)
10.0.0.26 --- external voicemail system.
2023/09/28 15:41:39.122897 10.0.0.117:40274 -> 10.0.0.177:5060
INVITE sip:10000010@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb>;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="10000006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:10000010@10.0.0.177",response="4a1d80ae375ae8d56d7b7c602e5bbcd4
",algorithm=MD5
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:39.124438 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP
10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport=40274;received=10.0.0.117
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Content-Length: 0
2023/09/28 15:41:39.125338 10.0.0.177:5060 -> 10.0.0.188:5678
INVITE sip:10000010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1
SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes>
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb;alias=10.0.0.117~40274~1>;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
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:39.126941 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 100 Trying
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes>
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
l: 0
2023/09/28 15:41:39.171314 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes>
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:39.172272 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes>
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp;alias=10.0.0.188~5678~1>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:59.129391 10.0.0.177:5060 -> 10.0.0.26:7066
INVITE sip:10000010@10.0.0.26:7066 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes>
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.1
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb;alias=10.0.0.117~40274~1>;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
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:59.129633 10.0.0.177:5060 -> 10.0.0.188:5678
CANCEL sip:10000010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1
SIP/2.0
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/28 15:41:59.130509 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 200 Ok
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes>
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:59.130543 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 200 Ok
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 CANCEL
m: <sip:10000010@10.0.0.188:5678;transport=udp>
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 9:43 AM, James Lipski
<jameslipski(a)protonmail.com> wrote:
Hello,
Thanks for the reply. I'm using the bundled/skeleton configurations just to test with
a few modifications (adding the actual voicemail server) however even with the skeleton
configurations, when the call goes unanswered, and the call forks to voicemail, the INVITE
packet is sent first, followed by the CANCEL to endpoint 2. The following is a SIP trace
of what I'm seeing:
10.0.0.117 -- Endpoint 1
10.0.0.177 -- Kamailio
10.0.0.110 -- Endpoint 2
10.0.0.26 -- Voicemail
2023/09/27 09:27:06.326167 10.0.0.117:42414 -> 10.0.0.177:5060
INVITE sip:10000008@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: sip:10000006@10.0.0.117:42414;line=aoec88fl;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="10000006",realm="10.0.0.177",nonce="ZRQu1mUULaq2rH8lPjaCtARPy4Wa7KfQ",uri="sip:10000008@10.0.0.177",response="a2cf69a439f25e97b238510377cc4900",algorithm=MD5
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.329198 10.0.0.177:5060 -> 10.0.0.117:42414
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP
10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414;received=10.0.0.117
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Content-Length: 0
2023/09/27 09:27:06.329914 10.0.0.177:5060 -> 10.0.0.110:5063
INVITE sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Record-Route: sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1;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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.385247 10.0.0.110:5063 -> 10.0.0.177:5060
SIP/2.0 100 Trying
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;received=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414
Server: OBIHAI/OBi200-3.2.1.5757
2023/09/27 09:27:06.461036 10.0.0.110:5063 -> 10.0.0.177:5060
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;received=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414
Server: OBIHAI/OBi200-3.2.1.5757
m: sip:10000008@10.0.0.110:5063
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO,
UPDATE
2023/09/27 09:27:06.462644 10.0.0.177:5060 -> 10.0.0.117:42414
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414
Server: OBIHAI/OBi200-3.2.1.5757
m: sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO,
UPDATE
2023/09/27 09:27:51.447756 10.0.0.177:5060 -> 10.0.0.26:7066
INVITE sip:10000008@10.0.0.26:7066 SIP/2.0
Record-Route: sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1;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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:51.466497 10.0.0.177:5060 -> 10.0.0.110:5063
CANCEL sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/27 09:27:51.466503 10.0.0.177:5060 -> 10.0.0.26:7066
ACK sip:10000008@10.0.0.26:7066 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177;tag=2faa70b9-a47d-42d0-87fc-779e397ebc7e
i: a62d14656998-uhh0lmce49oh
CSeq: 2 ACK
Max-Forwards: 69
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 2:04 AM, Daniel-Constantin Mierla via sr-users
sr-users(a)lists.kamailio.org wrote:
> Hello,
>
> default kamailio.cfg has a skeleton for doing serial forking to a
> voicemail server. Follow the token WITH_VOICEMAIL to discover the
> related snippets -- this can be a starting point to implement it in your
> config.
>
> Cheers,
> Daniel
>
> On 27.09.23 04:12, Alex Balashov via sr-users wrote:
>
> > Hi James,
> >
> > The difference you are describing is between serial and parallel forking. You
clearly want the former. There are a variety of ways to achieve that, and the answer will
depend on the code path taken to route to your voicemail server.
> >
> > -- Alex
> >
> > > On Sep 26, 2023, at 5:50 PM, James Lipski via sr-users
sr-users(a)lists.kamailio.org wrote:
> > >
> > > Hello,
> > >
> > > Is there a way to change the transaction order when a failure fork occurs
-- to explain, endpoint 1 calls endpoint 2. Call towards endpoint 2 goes unanswered, and
so the call forks to voicemail, I see that an INVITE is sent towards my voicemail server
first, followed by a CANCEL towards the endpoint; can I send the CANCEL first to the
endpoint and then INVITE towards my voicemail server. I'm essentially using the
bundled/sample configurations for testing.
> > >
> > > Thank you.__________________________________________________________
> > > 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:
> > > --
> > > Alex Balashov
> > > Principal Consultant
> > > Evariste Systems LLC
> > > Web: https://evaristesys.com
> > > Tel: +1-706-510-6800
> >
> > __________________________________________________________
> > 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
>
> __________________________________________________________
> 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:
29 Sep
29 Sep
12:05 a.m.
I can reproduce this behavior easily with the config below, but I'm not quite sure
how/why it matters.
request_route {
xinfo("[$ru] recieved\n");
$rd = "target2";
append_branch("sip:$rU@target1", "1.0");
t_load_contacts();
t_next_contacts();
t_on_failure("MANAGE_FAILURE");
t_on_branch("MANAGE_BRANCH");
t_set_fr(5000);
t_relay();
exit;
}
branch_route[MANAGE_BRANCH] {
xinfo("Sending [$ru]\n");
}
failure_route[MANAGE_FAILURE] {
if ( t_branch_timeout() ) {
xinfo("Branch timed out.\n");
}
if ( !t_next_contacts() ) {
send_reply("503", "Server Error");
exit;
}
t_on_failure("MANAGE_FAILURE");
t_relay();
}
-----Original Message-----
From: James Lipski via sr-users <sr-users(a)lists.kamailio.org>
Sent: Thursday, September 28, 2023 3:08 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: James Lipski <jameslipski(a)protonmail.com>
Subject: [SR-Users] Re: CANCEL first, then INVITE.
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello,
As with my previous update, I'm using the skeleton configurations (with minor changes,
such as defining an external voicemail destination) just for testing purposes. With the
skeleton configurations, I'm still seeing that the INVITE packet to the voicemail
server sent first, and then the CANCEL to the second endpoint (please see SIP trace
below). In this call example the second endpoint is a PBX, and is configured to route
unanswered calls towards it's own local voicemail system. Is there a way to switch the
behaviour so that the CANCEL packet towards endpoint 2 is sent FIRST; and then the INVITE
to the voicemail system second? Thank you.
10.0.0.117 --- snom (endpoint 1)
10.0.0.177 --- kamailio
10.0.0.188 --- PBX (endpoint 2)
10.0.0.26 --- external voicemail system.
2023/09/28 15:41:39.122897 10.0.0.117:40274 -> 10.0.0.177:5060 INVITE
sip:10000010@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb>;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="10000006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:10000010@10.0.0.177",response="4a1d80ae375ae8d56d7b7c602e5bbcd4
",algorithm=MD5
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:39.124438 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP
10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport=40274;received=10.0.0.117
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Content-Length: 0
2023/09/28 15:41:39.125338 10.0.0.177:5060 -> 10.0.0.188:5678 INVITE
sip:10000010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes>
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb;alias=10.0.0.117~40274~1>;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
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:39.126941 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 100 Trying
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes>
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
l: 0
2023/09/28 15:41:39.171314 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes>
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:39.172272 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes>
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp;alias=10.0.0.188~5678~1>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:59.129391 10.0.0.177:5060 -> 10.0.0.26:7066 INVITE
sip:10000010@10.0.0.26:7066 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes>
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.1
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb;alias=10.0.0.117~40274~1>;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
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:59.129633 10.0.0.177:5060 -> 10.0.0.188:5678 CANCEL
sip:10000010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/28 15:41:59.130509 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 200 Ok
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes>
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:59.130543 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 200 Ok
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 CANCEL
m: <sip:10000010@10.0.0.188:5678;transport=udp>
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 9:43 AM, James Lipski
<jameslipski(a)protonmail.com> wrote:
Hello,
Thanks for the reply. I'm using the bundled/skeleton configurations just to test with
a few modifications (adding the actual voicemail server) however even with the skeleton
configurations, when the call goes unanswered, and the call forks to voicemail, the INVITE
packet is sent first, followed by the CANCEL to endpoint 2. The following is a SIP trace
of what I'm seeing:
10.0.0.117 -- Endpoint 1
10.0.0.177 -- Kamailio
10.0.0.110 -- Endpoint 2
10.0.0.26 -- Voicemail
2023/09/27 09:27:06.326167 10.0.0.117:42414 -> 10.0.0.177:5060
INVITE sip:10000008@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: sip:10000006@10.0.0.117:42414;line=aoec88fl;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="10000006",realm="10.0.0.177",nonce="ZRQu1mUULaq2rH8lPjaCtARP
y4Wa7KfQ",uri="sip:10000008@10.0.0.177",response="a2cf69a439f25e97b238
510377cc4900",algorithm=MD5
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.329198 10.0.0.177:5060 -> 10.0.0.117:42414
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP
10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414;received=10.0
.0.117
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Content-Length: 0
2023/09/27 09:27:06.329914 10.0.0.177:5060 -> 10.0.0.110:5063
INVITE sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Record-Route: sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1;r
eg-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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.385247 10.0.0.110:5063 -> 10.0.0.177:5060
SIP/2.0 100 Trying
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;recei
ved=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
2023/09/27 09:27:06.461036 10.0.0.110:5063 -> 10.0.0.177:5060
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;recei
ved=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
m: sip:10000008@10.0.0.110:5063
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE
2023/09/27 09:27:06.462644 10.0.0.177:5060 -> 10.0.0.117:42414
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
m: sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE
2023/09/27 09:27:51.447756 10.0.0.177:5060 -> 10.0.0.26:7066
INVITE sip:10000008@10.0.0.26:7066 SIP/2.0
Record-Route: sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1;r
eg-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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:51.466497 10.0.0.177:5060 -> 10.0.0.110:5063
CANCEL sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/27 09:27:51.466503 10.0.0.177:5060 -> 10.0.0.26:7066
ACK sip:10000008@10.0.0.26:7066 SIP/2.0
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177;tag=2faa70b9-a47d-42d0-87fc-779e397ebc7e
i: a62d14656998-uhh0lmce49oh
CSeq: 2 ACK
Max-Forwards: 69
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 2:04 AM, Daniel-Constantin Mierla via sr-users
sr-users(a)lists.kamailio.org wrote:
> Hello,
>
> default kamailio.cfg has a skeleton for doing serial forking to a
> voicemail server. Follow the token WITH_VOICEMAIL to discover the
> related snippets -- this can be a starting point to implement it in
> your config.
>
> Cheers,
> Daniel
>
> On 27.09.23 04:12, Alex Balashov via sr-users wrote:
>
> > Hi James,
> >
> > The difference you are describing is between serial and parallel forking. You
clearly want the former. There are a variety of ways to achieve that, and the answer will
depend on the code path taken to route to your voicemail server.
> >
> > -- Alex
> >
> > > On Sep 26, 2023, at 5:50 PM, James Lipski via sr-users
sr-users(a)lists.kamailio.org wrote:
> > >
> > > Hello,
> > >
> > > Is there a way to change the transaction order when a failure fork occurs
-- to explain, endpoint 1 calls endpoint 2. Call towards endpoint 2 goes unanswered, and
so the call forks to voicemail, I see that an INVITE is sent towards my voicemail server
first, followed by a CANCEL towards the endpoint; can I send the CANCEL first to the
endpoint and then INVITE towards my voicemail server. I'm essentially using the
bundled/sample configurations for testing.
> > >
> > > Thank
> > > you.__________________________________________________________
> > > 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:
> > > --
> > > Alex Balashov
> > > Principal Consultant
> > > Evariste Systems LLC
> > > Web:
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > 2Fevaristesys.com%2F&data=05%7C01%7Cbkaufman%40bcmone.com%7C73b1
> > > 320140764ada4bbf08dbc0600f7a%7Cafc1818e7b6848568913201b9396c4fc%
> > > 7C1%7C0%7C638315291068700436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> > > C%7C%7C&sdata=opsgjhZGjuZd%2Bam%2Fijw3tgXcofOZOee4u3IkAlyEc90%3D
> > > &reserved=0
> > > Tel: +1-706-510-6800
> >
> > __________________________________________________________
> > 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
>
> __________________________________________________________
> 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:
__________________________________________________________
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:
12:13 a.m.
Also, since a picture is worth a thousand words, it can be seen here that the INVITE for
the new branch is sent before the CANCEL of the earlier branch. Again, I'm not sure
why this would make any difference, but it does seem to be the current behavior.
[A screenshot of a computer screen Description automatically generated]
-----Original Message-----
From: Ben Kaufman via sr-users <sr-users(a)lists.kamailio.org Sent: Thursday, September 28, 2023 5:05 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org Cc: James Lipski
<jameslipski(a)protonmail.com>om>; Ben Kaufman <bkaufman(a)bcmone.com Subject: [SR-Users] Re: CANCEL first, then
INVITE.
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
I can reproduce this behavior easily with the config below, but I'm not quite sure
how/why it matters.
request_route {
xinfo("[$ru] recieved\n");
$rd = "target2";
append_branch("sip:$rU@target1", "1.0");
t_load_contacts();
t_next_contacts();
t_on_failure("MANAGE_FAILURE");
t_on_branch("MANAGE_BRANCH");
t_set_fr(5000);
t_relay();
exit;
}
branch_route[MANAGE_BRANCH] {
xinfo("Sending [$ru]\n");
}
failure_route[MANAGE_FAILURE] {
if ( t_branch_timeout() ) {
xinfo("Branch timed out.\n");
}
if ( !t_next_contacts() ) {
send_reply("503", "Server Error");
exit;
}
t_on_failure("MANAGE_FAILURE");
t_relay();
}
-----Original Message-----
From: James Lipski via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
Sent: Thursday, September 28, 2023 3:08 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
Cc: James Lipski
<jameslipski@protonmail.com<mailto:jameslipski@protonmail.com>
Subject: [SR-Users] Re: CANCEL first, then INVITE.
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello,
As with my previous update, I'm using the skeleton configurations (with minor changes,
such as defining an external voicemail destination) just for testing purposes. With the
skeleton configurations, I'm still seeing that the INVITE packet to the voicemail
server sent first, and then the CANCEL to the second endpoint (please see SIP trace
below). In this call example the second endpoint is a PBX, and is configured to route
unanswered calls towards it's own local voicemail system. Is there a way to switch the
behaviour so that the CANCEL packet towards endpoint 2 is sent FIRST; and then the INVITE
to the voicemail system second? Thank you.
10.0.0.117 --- snom (endpoint 1)
10.0.0.177 --- kamailio
10.0.0.188 --- PBX (endpoint 2)
10.0.0.26 --- external voicemail system.
2023/09/28 15:41:39.122897 10.0.0.117:40274 -> 10.0.0.177:5060 INVITE
sip:10000010@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb>;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="10000006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:10000010@10.0.0.177",response="4a1d80ae375ae8d56d7b7c602e5bbcd4
",algorithm=MD5
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:39.124438 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP
10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport=40274;received=10.0.0.117
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Content-Length: 0
2023/09/28 15:41:39.125338 10.0.0.177:5060 -> 10.0.0.188:5678 INVITE
sip:10000010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb;alias=10.0.0.117~40274~1>;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
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:39.126941 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 100 Trying
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
l: 0
2023/09/28 15:41:39.171314 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:39.172272 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp;alias=10.0.0.188~5678~1
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:59.129391 10.0.0.177:5060 -> 10.0.0.26:7066 INVITE
sip:10000010@10.0.0.26:7066 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.1
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb;alias=10.0.0.117~40274~1>;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
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:59.129633 10.0.0.177:5060 -> 10.0.0.188:5678 CANCEL
sip:10000010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/28 15:41:59.130509 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 200 Ok
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:59.130543 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 200 Ok
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 CANCEL
m: <sip:10000010@10.0.0.188:5678;transport=udp
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 9:43 AM, James Lipski
<jameslipski@protonmail.com<mailto:jameslipski@protonmail.com>> wrote:
>
> > >
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
Hello,
Thanks for the reply. I'm using the
bundled/skeleton configurations just to test with a few modifications (adding the actual
voicemail server) however even with the skeleton configurations, when the call goes
unanswered, and the call forks to voicemail, the INVITE packet is sent first, followed by
the CANCEL to endpoint 2. The following is a SIP trace of what I'm seeing:
10.0.0.117 -- Endpoint 1
10.0.0.177 -- Kamailio
10.0.0.110 -- Endpoint 2
10.0.0.26 -- Voicemail
2023/09/27 09:27:06.326167 10.0.0.117:42414 ->
10.0.0.177:5060
INVITE sip:10000008@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP
10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;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="10000006",realm="10.0.0.177",nonce="ZRQu1mUULaq2rH8lPjaCtARP
y4Wa7KfQ",uri="sip:10000008@10.0.0.177",response="a2cf69a439f25e97b238
510377cc4900",algorithm=MD5
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call c=IN
IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.329198 10.0.0.177:5060 ->
10.0.0.117:42414
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP
10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414;received=10.0
.0.117
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Content-Length: 0
2023/09/27 09:27:06.329914 10.0.0.177:5060 ->
10.0.0.110:5063
INVITE
sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Record-Route: sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1;r
eg-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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call c=IN
IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.385247 10.0.0.110:5063 ->
10.0.0.177:5060
SIP/2.0 100 Trying
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;recei
ved=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
2023/09/27 09:27:06.461036 10.0.0.110:5063 ->
10.0.0.177:5060
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;recei
ved=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
m: sip:10000008@10.0.0.110:5063
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS,
NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE
2023/09/27 09:27:06.462644 10.0.0.177:5060 ->
10.0.0.117:42414
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
m:
sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS,
NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE
2023/09/27 09:27:51.447756 10.0.0.177:5060 ->
10.0.0.26:7066
INVITE sip:10000008@10.0.0.26:7066 SIP/2.0
Record-Route: sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1;r
eg-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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call c=IN
IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:51.466497 10.0.0.177:5060 ->
10.0.0.110:5063
CANCEL
sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/27 09:27:51.466503 10.0.0.177:5060 ->
10.0.0.26:7066
ACK sip:10000008@10.0.0.26:7066 SIP/2.0
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t:
sip:10000008@10.0.0.177;tag=2faa70b9-a47d-42d0-87fc-779e397ebc7e
i: a62d14656998-uhh0lmce49oh
CSeq: 2 ACK
Max-Forwards: 69
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 2:04 AM,
Daniel-Constantin Mierla via sr-users
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> wrote:
Hello,
> > default kamailio.cfg has a skeleton for doing
serial forking to a
> voicemail server. Follow the token WITH_VOICEMAIL
to discover the
> related snippets -- this can be a starting point
to implement it in
> your config.
> > Cheers,
> Daniel
> > On 27.09.23 04:12, Alex Balashov via sr-users
wrote:
> > > Hi James,
> > > > The difference you are describing is between
serial and parallel forking. You clearly want the former. There are a variety of ways to
achieve that, and the answer will depend on the code path taken to route to your voicemail
server.
> > > > -- Alex
> > > > > On Sep 26, 2023, at 5:50 PM, James
Lipski via sr-users sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
wrote:
> > > Hello,
> > > > > > Is there a way to change the
transaction order when a failure fork occurs -- to explain, endpoint 1 calls endpoint 2.
Call towards endpoint 2 goes unanswered, and so the call forks to voicemail, I see that an
INVITE is sent towards my voicemail server first, followed by a CANCEL towards the
endpoint; can I send the CANCEL first to the endpoint and then INVITE towards my voicemail
server. I'm essentially using the bundled/sample configurations for testing.
> > > > > > Thank
> > >
you.__________________________________________________________
> > > Kamailio - Users Mailing List - Non
Commercial Discussions To
> > > > unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org > > > Important: keep the mailing list in the
recipients, do not reply only to the sender!
> > > Edit mailing list options or
unsubscribe:
> > > --
> > > Alex Balashov
> > > Principal Consultant
> > > Evariste Systems LLC
> > > Web:
> > > >
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%<https:/… > > >
2Fevaristesys.com%2F&data=05%7C01%7Cbkaufman%40bcmone.com%7C73b1
> > >
320140764ada4bbf08dbc0600f7a%7Cafc1818e7b6848568913201b9396c4fc%
> > >
7C1%7C0%7C638315291068700436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > >
wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> > >
C%7C%7C&sdata=opsgjhZGjuZd%2Bam%2Fijw3tgXcofOZOee4u3IkAlyEc90%3D
> > > &reserved=0
> > > Tel: +1-706-510-6800
> > > >
__________________________________________________________
> > Kamailio - Users Mailing List - Non
Commercial Discussions To
> > > unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@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
> >
__________________________________________________________
> Kamailio - Users Mailing List - Non Commercial
Discussions To
> > unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org > Important: keep the mailing list in the
recipients, do not reply only to the sender!
> Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org
4:35 a.m.
Hello,
To add to my previous reply, the reason for asking whether if it's possible to change
the order of transactions (CANCEL first, then INVITE) is I've ran into issues where 2
200OKs are being received roughly at the same time; such as the call example from my
previous post, where the receiving UA sends a 200OK for CSeq INVITE and a 200OK for CSeq
CANCEL (only tested with 3CX, and Asterisk as the receiving UA); which seems to cause a
conflict.
When testing this call scenario with another platform (an aged proxy platform that
hopefully will be replaced with kamailio), when the call forks, it sends a CANCEL first to
the second endpoint and the INVITE to the voicemail server.
Thank you.
------- Original Message -------
On Thursday, September 28th, 2023 at 6:13 PM, Ben Kaufman <bkaufman(a)bcmone.com>
wrote:
Also, since a picture is worth a thousand words, it
can be seen here that the INVITE for the new branch is sent before the CANCEL of the
earlier branch. Again, I’m not sure why this would make any difference, but it does seem
to be the current behavior.
[A screenshot of a computer screen
Description automatically generated]
-----Original Message-----
From: Ben Kaufman via sr-users <sr-users(a)lists.kamailio.org Sent: Thursday, September 28, 2023 5:05 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org Cc: James Lipski
<jameslipski(a)protonmail.com>om>; Ben Kaufman <bkaufman(a)bcmone.com Subject: [SR-Users] Re: CANCEL first, then
INVITE.
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
I can reproduce this behavior easily with the config below, but I'm not quite sure
how/why it matters.
request_route {
xinfo("[$ru] recieved\n");
$rd = "target2";
append_branch("sip:$rU@target1", "1.0");
t_load_contacts();
t_next_contacts();
t_on_failure("MANAGE_FAILURE");
t_on_branch("MANAGE_BRANCH");
t_set_fr(5000);
t_relay();
exit;
}
branch_route[MANAGE_BRANCH] {
xinfo("Sending [$ru]\n");
}
failure_route[MANAGE_FAILURE] {
if ( t_branch_timeout() ) {
xinfo("Branch timed out.\n");
}
if ( !t_next_contacts() ) {
send_reply("503", "Server Error");
exit;
}
t_on_failure("MANAGE_FAILURE");
t_relay();
}
-----Original Message-----
From: James Lipski via sr-users <sr-users(a)lists.kamailio.org
Sent: Thursday, September 28, 2023 3:08 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org
Cc: James Lipski <jameslipski(a)protonmail.com
Subject: [SR-Users] Re: CANCEL first, then INVITE.
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello,
As with my previous update, I'm using the skeleton configurations (with minor
changes, such as defining an external voicemail destination) just for testing purposes.
With the skeleton configurations, I'm still seeing that the INVITE packet to the
voicemail server sent first, and then the CANCEL to the second endpoint (please see SIP
trace below). In this call example the second endpoint is a PBX, and is configured to
route unanswered calls towards it's own local voicemail system. Is there a way to
switch the behaviour so that the CANCEL packet towards endpoint 2 is sent FIRST; and then
the INVITE to the voicemail system second? Thank you.
10.0.0.117 --- snom (endpoint 1)
10.0.0.177 --- kamailio
10.0.0.188 --- PBX (endpoint 2)
10.0.0.26 --- external voicemail system.
2023/09/28 15:41:39.122897 10.0.0.117:40274 -> 10.0.0.177:5060 INVITE
sip:10000010@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb>;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="10000006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:10000010@10.0.0.177",response="4a1d80ae375ae8d56d7b7c602e5bbcd4
",algorithm=MD5
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:39.124438 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP
10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport=40274;received=10.0.0.117
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Content-Length: 0
2023/09/28 15:41:39.125338 10.0.0.177:5060 -> 10.0.0.188:5678 INVITE
sip:10000010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb;alias=10.0.0.117~40274~1>;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
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:39.126941 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 100 Trying
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
l: 0
2023/09/28 15:41:39.171314 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:39.172272 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp;alias=10.0.0.188~5678~1
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:59.129391 10.0.0.177:5060 -> 10.0.0.26:7066 INVITE
sip:10000010@10.0.0.26:7066 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.1
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb;alias=10.0.0.117~40274~1>;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
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:59.129633 10.0.0.177:5060 -> 10.0.0.188:5678 CANCEL
sip:10000010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/28 15:41:59.130509 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 200 Ok
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:59.130543 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 200 Ok
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 CANCEL
m: <sip:10000010@10.0.0.188:5678;transport=udp
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 9:43 AM, James Lipski
<jameslipski(a)protonmail.com> wrote:
>
> > >
Hello,
Thanks for the reply. I'm using the
bundled/skeleton configurations just to test with a few modifications (adding the actual
voicemail server) however even with the skeleton configurations, when the call goes
unanswered, and the call forks to voicemail, the INVITE packet is sent first, followed by
the CANCEL to endpoint 2. The following is a SIP trace of what I'm seeing:
10.0.0.117 -- Endpoint 1
10.0.0.177 -- Kamailio
10.0.0.110 -- Endpoint 2
10.0.0.26 -- Voicemail
2023/09/27 09:27:06.326167 10.0.0.117:42414 ->
10.0.0.177:5060
INVITE sip:10000008@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP
10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;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="10000006",realm="10.0.0.177",nonce="ZRQu1mUULaq2rH8lPjaCtARP
y4Wa7KfQ",uri="sip:10000008@10.0.0.177",response="a2cf69a439f25e97b238
510377cc4900",algorithm=MD5
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.329198 10.0.0.177:5060 ->
10.0.0.117:42414
SIP/2.0 100 trying -- your call is important to
us
v: SIP/2.0/UDP
10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414;received=10.0
.0.117
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Content-Length: 0
2023/09/27 09:27:06.329914 10.0.0.177:5060 ->
10.0.0.110:5063
INVITE
sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Record-Route: sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1;r
eg-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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.385247 10.0.0.110:5063 ->
10.0.0.177:5060
SIP/2.0 100 Trying
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t:
sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;recei
ved=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
2023/09/27 09:27:06.461036 10.0.0.110:5063 ->
10.0.0.177:5060
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t:
sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;recei
ved=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
m: sip:10000008@10.0.0.110:5063
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS,
NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE
2023/09/27 09:27:06.462644 10.0.0.177:5060 ->
10.0.0.117:42414
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t:
sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
m:
sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS,
NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE
2023/09/27 09:27:51.447756 10.0.0.177:5060 ->
10.0.0.26:7066
INVITE sip:10000008@10.0.0.26:7066 SIP/2.0
Record-Route: sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1;r
eg-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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:51.466497 10.0.0.177:5060 ->
10.0.0.110:5063
CANCEL
sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/27 09:27:51.466503 10.0.0.177:5060 ->
10.0.0.26:7066
ACK sip:10000008@10.0.0.26:7066 SIP/2.0
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t:
sip:10000008@10.0.0.177;tag=2faa70b9-a47d-42d0-87fc-779e397ebc7e
i: a62d14656998-uhh0lmce49oh
CSeq: 2 ACK
Max-Forwards: 69
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 2:04 AM,
Daniel-Constantin Mierla via sr-users sr-users(a)lists.kamailio.org wrote:
Hello,
> > default kamailio.cfg has a skeleton for
doing serial forking to a
> voicemail server. Follow the token
WITH_VOICEMAIL to discover the
> related snippets -- this can be a starting
point to implement it in
> your config.
> > Cheers,
> Daniel
> > On 27.09.23 04:12, Alex Balashov via
sr-users wrote:
> > > Hi James,
> > > > The difference you are describing is
between serial and parallel forking. You clearly want the former. There are a variety of
ways to achieve that, and the answer will depend on the code path taken to route to your
voicemail server.
> > > > -- Alex
> > > > > On Sep 26, 2023, at 5:50 PM, James
Lipski via sr-users sr-users(a)lists.kamailio.org wrote:
> > > Hello,
> > > > > > Is there a way to change the
transaction order when a failure fork occurs -- to explain, endpoint 1 calls endpoint 2.
Call towards endpoint 2 goes unanswered, and so the call forks to voicemail, I see that an
INVITE is sent towards my voicemail server first, followed by a CANCEL towards the
endpoint; can I send the CANCEL first to the endpoint and then INVITE towards my voicemail
server. I'm essentially using the bundled/sample configurations for testing.
> > > > > > Thank
> > >
you.__________________________________________________________
> > > 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:
> > > --
> > > Alex Balashov
> > > Principal Consultant
> > > Evariste Systems LLC
> > > Web:
> > >
2Fevaristesys.com%2F&data=05%7C01%7Cbkaufman%40bcmone.com%7C73b1
> > >
320140764ada4bbf08dbc0600f7a%7Cafc1818e7b6848568913201b9396c4fc%
> > >
7C1%7C0%7C638315291068700436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > >
wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> > >
C%7C%7C&sdata=opsgjhZGjuZd%2Bam%2Fijw3tgXcofOZOee4u3IkAlyEc90%3D
> > > &reserved=0
> > > Tel: +1-706-510-6800
> > > >
__________________________________________________________
> > 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
> >
__________________________________________________________
> 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:
__________________________________________________________
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:
__________________________________________________________
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: 
5:07 p.m.
I took some time to diagram out your call flow since reading a text capture is a bit
difficult to visualize. Included as both the text (which will look bad on anything that
doesn't use monospaced fonts) as well as a screen capture.
Given this, I'm still not clear on what change in behavior you'd expect if frames
number 7 and 8 were sent in reverse order. The new INVITE is sent to a completely
different server, so the PBX shouldn't have any awareness of this message, and only
get that it's cancelled. If you're looking at it in terms of trying to shave off
the sliver of time difference and have the cancel sent 242 microseconds earlier - Note
that it took 20 seconds from the last received message to when the cancel was sent. 250
micorseconds isn't a drop in this bucket.
snom phone Kamailio PBX Voicemail
10.0.0.117 10.0.0.177 10.0.0.188 10.0.0.26
--------------------+------------------+------------------+----------------+-----
1 15:41:39.122897 | ==== INVITE ===> | | |
+ 0.001541 | | | |
2 15:41:39.124438 | <=== 100 ==== | | |
+ 0.000900 | | | |
3 15:41:39.125338 | | ==== INVITE ===> | |
+ 0.001603 | | | |
4 15:41:39.126941 | | <=== 100 ==== | |
+ 0.044373 | | | |
5 15:41:39.171314 | | <=== 183 ==== | |
+ 0.000957 | | | |
6 15:41:39.172272 | <=== 183 ==== | | |
+ 19.957119 | | | |
7 15:41:59.129391 | | ============= INVITE ===========> |
+ 0.000242 | | | |
8 15:41:59.129633 | | ==== CANCEL ===> | |
+ 0.000876 | | | |
9 15:41:59.130509 | | <== 200 (INV) == | |
+ 0.000033 | | | |
10 15:41:59.130543 | | <== 200 (CAN) == | |
[A white paper with black text Description automatically generated]
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/
[img]<https://www.siptrunk.com/
[img]<https://www.flowroute.com/
From: James Lipski via sr-users <sr-users(a)lists.kamailio.org Sent: Thursday, September 28, 2023 9:36 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org Cc: James Lipski
<jameslipski(a)protonmail.com Subject: [SR-Users]
Re: CANCEL first, then INVITE.
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello,
To add to my previous reply, the reason for asking whether if it's possible to change
the order of transactions (CANCEL first, then INVITE) is I've ran into issues where 2
200OKs are being received roughly at the same time; such as the call example from my
previous post, where the receiving UA sends a 200OK for CSeq INVITE and a 200OK for CSeq
CANCEL (only tested with 3CX, and Asterisk as the receiving UA); which seems to cause a
conflict.
When testing this call scenario with another platform (an aged proxy platform that
hopefully will be replaced with kamailio), when the call forks, it sends a CANCEL first to
the second endpoint and the INVITE to the voicemail server.
Thank you.
------- Original Message -------
On Thursday, September 28th, 2023 at 6:13 PM, Ben Kaufman
<bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>> wrote:
Also, since a picture is worth a thousand words, it can be seen here that the INVITE for
the new branch is sent before the CANCEL of the earlier branch. Again, I'm not sure
why this would make any difference, but it does seem to be the current behavior.
[A screenshot of a computer screen Description automatically generated]
-----Original Message-----
From: Ben Kaufman via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Sent: Thursday, September 28, 2023 5:05 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Cc: James Lipski
<jameslipski@protonmail.com<mailto:jameslipski@protonmail.com>>; Ben Kaufman
<bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
Subject: [SR-Users] Re: CANCEL first, then INVITE.
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
I can reproduce this behavior easily with the config below, but I'm not quite sure
how/why it matters.
request_route {
xinfo("[$ru] recieved\n");
$rd = "target2";
append_branch("sip:$rU@target1", "1.0");
t_load_contacts();
t_next_contacts();
t_on_failure("MANAGE_FAILURE");
t_on_branch("MANAGE_BRANCH");
t_set_fr(5000);
t_relay();
exit;
}
branch_route[MANAGE_BRANCH] {
xinfo("Sending [$ru]\n");
}
failure_route[MANAGE_FAILURE] {
if ( t_branch_timeout() ) {
xinfo("Branch timed out.\n");
}
if ( !t_next_contacts() ) {
send_reply("503", "Server Error");
exit;
}
t_on_failure("MANAGE_FAILURE");
t_relay();
}
-----Original Message-----
From: James Lipski via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
Sent: Thursday, September 28, 2023 3:08 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
Cc: James Lipski
<jameslipski@protonmail.com<mailto:jameslipski@protonmail.com>
Subject: [SR-Users] Re: CANCEL first, then INVITE.
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello,
As with my previous update, I'm using the skeleton configurations (with minor changes,
such as defining an external voicemail destination) just for testing purposes. With the
skeleton configurations, I'm still seeing that the INVITE packet to the voicemail
server sent first, and then the CANCEL to the second endpoint (please see SIP trace
below). In this call example the second endpoint is a PBX, and is configured to route
unanswered calls towards it's own local voicemail system. Is there a way to switch the
behaviour so that the CANCEL packet towards endpoint 2 is sent FIRST; and then the INVITE
to the voicemail system second? Thank you.
10.0.0.117 --- snom (endpoint 1)
10.0.0.177 --- kamailio
10.0.0.188 --- PBX (endpoint 2)
10.0.0.26 --- external voicemail system.
2023/09/28 15:41:39.122897 10.0.0.117:40274 -> 10.0.0.177:5060 INVITE
sip:10000010@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb>;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="10000006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:10000010@10.0.0.177",response="4a1d80ae375ae8d56d7b7c602e5bbcd4
",algorithm=MD5
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:39.124438 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP
10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport=40274;received=10.0.0.117
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Content-Length: 0
2023/09/28 15:41:39.125338 10.0.0.177:5060 -> 10.0.0.188:5678 INVITE
sip:10000010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb;alias=10.0.0.117~40274~1>;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
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:39.126941 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 100 Trying
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
l: 0
2023/09/28 15:41:39.171314 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:39.172272 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp;alias=10.0.0.188~5678~1
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:59.129391 10.0.0.177:5060 -> 10.0.0.26:7066 INVITE
sip:10000010@10.0.0.26:7066 SIP/2.0
Record-Route: <sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.1
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: <sip:10000006@10.0.0.117:40274;line=y3jwlgtb;alias=10.0.0.117~40274~1>;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
c: application/sdp
l: 315
v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 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
2023/09/28 15:41:59.129633 10.0.0.177:5060 -> 10.0.0.188:5678 CANCEL
sip:10000010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/28 15:41:59.130509 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 200 Ok
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: <sip:10.0.0.177;lr;nat=yes
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: <sip:10000010@10.0.0.188:5678;transport=udp
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247
v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv
2023/09/28 15:41:59.130543 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 200 Ok
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
f: <sip:10000006@10.0.0.177>;tag=pqxa29jt8v
t: <sip:10000010@10.0.0.177>;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 CANCEL
m: <sip:10000010@10.0.0.188:5678;transport=udp
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 9:43 AM, James Lipski
<jameslipski@protonmail.com<mailto:jameslipski@protonmail.com>> wrote:
>
> > >
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
Hello,
Thanks for the reply. I'm using the
bundled/skeleton configurations just to test with a few modifications (adding the actual
voicemail server) however even with the skeleton configurations, when the call goes
unanswered, and the call forks to voicemail, the INVITE packet is sent first, followed by
the CANCEL to endpoint 2. The following is a SIP trace of what I'm seeing:
10.0.0.117 -- Endpoint 1
10.0.0.177 -- Kamailio
10.0.0.110 -- Endpoint 2
10.0.0.26 -- Voicemail
2023/09/27 09:27:06.326167 10.0.0.117:42414 ->
10.0.0.177:5060
INVITE sip:10000008@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP
10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;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="10000006",realm="10.0.0.177",nonce="ZRQu1mUULaq2rH8lPjaCtARP
y4Wa7KfQ",uri="sip:10000008@10.0.0.177",response="a2cf69a439f25e97b238
510377cc4900",algorithm=MD5
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call c=IN
IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.329198 10.0.0.177:5060 ->
10.0.0.117:42414
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP
10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport=42414;received=10.0
.0.117
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Content-Length: 0
2023/09/27 09:27:06.329914 10.0.0.177:5060 ->
10.0.0.110:5063
INVITE
sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Record-Route: sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1;r
eg-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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call c=IN
IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:06.385247 10.0.0.110:5063 ->
10.0.0.177:5060
SIP/2.0 100 Trying
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;recei
ved=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
2023/09/27 09:27:06.461036 10.0.0.110:5063 ->
10.0.0.177:5060
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
v: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0;recei
ved=10.0.0.177;rport=5060
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
m: sip:10000008@10.0.0.110:5063
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS,
NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE
2023/09/27 09:27:06.462644 10.0.0.177:5060 ->
10.0.0.117:42414
SIP/2.0 180 Ringing
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
l: 0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
Record-Route: sip:10.0.0.177;lr;nat=yes
t: sip:10000008@10.0.0.177;tag=SP49be74061f6fb65ae
Via: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
Server: OBIHAI/OBi200-3.2.1.5757
m:
sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS,
NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE
2023/09/27 09:27:51.447756 10.0.0.177:5060 ->
10.0.0.26:7066
INVITE sip:10000008@10.0.0.26:7066 SIP/2.0
Record-Route: sip:10.0.0.177;lr;nat=yes
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
v: SIP/2.0/UDP
10.0.0.117:42414;received=10.0.0.117;branch=z9hG4bK-dyp7uuyl7zjs;rport
=42414
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m:
sip:10000006@10.0.0.117:42414;line=aoec88fl;alias=10.0.0.117~42414~1;r
eg-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
c: application/sdp
l: 311
v=0
o=root 44632463 44632463 IN IP4 10.0.0.117 s=call c=IN
IP4 10.0.0.117
t=0 0
m=audio 65348 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
2023/09/27 09:27:51.466497 10.0.0.177:5060 ->
10.0.0.110:5063
CANCEL
sip:10000008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.0
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t: sip:10000008@10.0.0.177
i: a62d14656998-uhh0lmce49oh
CSeq: 2 CANCEL
Max-Forwards: 69
l: 0
2023/09/27 09:27:51.466503 10.0.0.177:5060 ->
10.0.0.26:7066
ACK sip:10000008@10.0.0.26:7066 SIP/2.0
Via: SIP/2.0/UDP
10.0.0.177;branch=z9hG4bKa57d.d96bf39b755c51e53e995361b9567dc6.1
f: sip:10000006@10.0.0.177;tag=rsxulncekf
t:
sip:10000008@10.0.0.177;tag=2faa70b9-a47d-42d0-87fc-779e397ebc7e
i: a62d14656998-uhh0lmce49oh
CSeq: 2 ACK
Max-Forwards: 69
l: 0
------- Original Message -------
On Wednesday, September 27th, 2023 at 2:04 AM,
Daniel-Constantin Mierla via sr-users
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> wrote:
Hello,
> > default kamailio.cfg has a skeleton for doing
serial forking to a
> voicemail server. Follow the token WITH_VOICEMAIL
to discover the
> related snippets -- this can be a starting point
to implement it in
> your config.
> > Cheers,
> Daniel
> > On 27.09.23 04:12, Alex Balashov via sr-users
wrote:
> > > Hi James,
> > > > The difference you are describing is between
serial and parallel forking. You clearly want the former. There are a variety of ways to
achieve that, and the answer will depend on the code path taken to route to your voicemail
server.
> > > > -- Alex
> > > > > On Sep 26, 2023, at 5:50 PM, James
Lipski via sr-users sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
wrote:
> > > Hello,
> > > > > > Is there a way to change the
transaction order when a failure fork occurs -- to explain, endpoint 1 calls endpoint 2.
Call towards endpoint 2 goes unanswered, and so the call forks to voicemail, I see that an
INVITE is sent towards my voicemail server first, followed by a CANCEL towards the
endpoint; can I send the CANCEL first to the endpoint and then INVITE towards my voicemail
server. I'm essentially using the bundled/sample configurations for testing.
> > > > > > Thank
> > >
you.__________________________________________________________
> > > Kamailio - Users Mailing List - Non
Commercial Discussions To
> > > > unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org > > > Important: keep the mailing list in the
recipients, do not reply only to the sender!
> > > Edit mailing list options or
unsubscribe:
> > > --
> > > Alex Balashov
> > > Principal Consultant
> > > Evariste Systems LLC
> > > Web:
> > > >
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%<https:/… > > >
2Fevaristesys.com%2F&data=05%7C01%7Cbkaufman%40bcmone.com%7C73b1
> > >
320140764ada4bbf08dbc0600f7a%7Cafc1818e7b6848568913201b9396c4fc%
> > >
7C1%7C0%7C638315291068700436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > >
wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> > >
C%7C%7C&sdata=opsgjhZGjuZd%2Bam%2Fijw3tgXcofOZOee4u3IkAlyEc90%3D
> > > &reserved=0
> > > Tel: +1-706-510-6800
> > > >
__________________________________________________________
> > Kamailio - Users Mailing List - Non
Commercial Discussions To
> > > unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@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
> >
__________________________________________________________
> Kamailio - Users Mailing List - Non Commercial
Discussions To
> > unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org > Important: keep the mailing list in the
recipients, do not reply only to the sender!
> Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org
7 Oct
7 Oct
4:01 p.m.
Hello,
Thanks for the reply. Would there be a way to prevent a situation where kamailio would
receive 2 200OKs from being received (1 200OK for CSeq INVITE and 1 200OK for CSeq
CANCEL)? As of right now, at least with my test configuration (using the skeleton
configuration) it seems to be easily replicable. I'm trying to prevent a situation
where "t_set_fr" and the UA's internal timeout fire at the same time causing
2 200OKs from sent by the UA (as described on my previous message).
Thank you.
9 Oct
9 Oct
9:12 p.m.
TM should be able to different between the 200 reply to the locally generated CANCEL and
the 200 OK for the relayed INVITE. You shouldn't have a problrm. Can you post your
config?
Kaufman
________________________________
From: James Lipski via sr-users <sr-users(a)lists.kamailio.org>
Sent: Saturday, October 7, 2023 9:01:03 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: James Lipski <jameslipski(a)protonmail.com>
Subject: [SR-Users] Re: CANCEL first, then INVITE.
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello,
Thanks for the reply. Would there be a way to prevent a situation where kamailio would
receive 2 200OKs from being received (1 200OK for CSeq INVITE and 1 200OK for CSeq
CANCEL)? As of right now, at least with my test configuration (using the skeleton
configuration) it seems to be easily replicable. I'm trying to prevent a situation
where "t_set_fr" and the UA's internal timeout fire at the same time causing
2 200OKs from sent by the UA (as described on my previous message).
Thank you.
212
days inactive
225
days old
10 comments
4 participants
participants (4)
-
Alex Balashov -
Ben Kaufman -
Daniel-Constantin Mierla -
James Lipski