[SR-Users] Re: CANCEL first, then INVITE.
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 Sent: Saturday, October 7, 2023 9:01:03 AM To: Kamailio (SER) - Users Mailing List Cc: James Lipski 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. __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: CANCEL first, then INVITE.
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.__ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: CANCEL first, then INVITE.
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
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
> Sent: Thursday, September 28, 2023 5:05 PM
> To: Kamailio (SER) - Users Mailing List
> Cc: James Lipski ; Ben Kaufman
>
> 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
>
> Sent: Thursday, September 28, 2023 3:08 PM
>
> To: Kamailio (SER) - Users Mailing List
>
> Cc: James Lipski
>
> 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:1010@10.0.0.177 SIP/2.0
>
> v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
>
> f: ;tag=pqxa29jt8v
>
> t:
>
> i: f1d61565275f-tqgd64ng8qmq
>
> CSeq: 2 INVITE
>
> Max-Forwards: 70
>
> User-Agent: snomD785/10.1.159.12
>
> m: ;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="1006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:1010@10.0.0.177",response="4a1d80ae375ae8d56d7b7c602e5bbcd4
>
> ",algorithm=MD5
>
> c: application/sdp
>
> l: 315
[SR-Users] Re: CANCEL first, then INVITE.
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
Sent: Thursday, September 28, 2023 5:05 PM
To: Kamailio (SER) - Users Mailing List
Cc: James Lipski ; Ben Kaufman
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
mailto:sr-users@lists.kamailio.org>>
Sent: Thursday, September 28, 2023 3:08 PM
To: Kamailio (SER) - Users Mailing List
mailto:sr-users@lists.kamailio.org>>
Cc: James Lipski mailto:jameslip...@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:1010@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
f: ;tag=pqxa29jt8v
t:
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: ;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="1006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:1010@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: ;tag=pqxa29jt8v
t:
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:1010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1
SIP/2.0
Record-Route:
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: ;tag=pqxa29jt8v
t:
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m:
;reg-id=1
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK,
MESSAGE, INFO, UPDATE
All
[SR-Users] Re: CANCEL first, then INVITE.
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
Sent: Thursday, September 28, 2023 3:08 PM
To: Kamailio (SER) - Users Mailing List
Cc: James Lipski
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:1010@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
f: ;tag=pqxa29jt8v
t:
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: ;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="1006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:1010@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: ;tag=pqxa29jt8v
t:
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:1010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1
SIP/2.0
Record-Route:
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: ;tag=pqxa29jt8v
t:
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m:
;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:
f: ;tag=pqxa29jt8v
t: ;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/
[SR-Users] Re: CANCEL first, then INVITE.
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:1010@10.0.0.177 SIP/2.0 v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport f: ;tag=pqxa29jt8v t: i: f1d61565275f-tqgd64ng8qmq CSeq: 2 INVITE Max-Forwards: 70 User-Agent: snomD785/10.1.159.12 m: ;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="1006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:1010@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: ;tag=pqxa29jt8v t: 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:1010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1 SIP/2.0 Record-Route: 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: ;tag=pqxa29jt8v t: i: f1d61565275f-tqgd64ng8qmq CSeq: 2 INVITE Max-Forwards: 69 User-Agent: snomD785/10.1.159.12 m: ;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: f: ;tag=pqxa29jt8v t: ;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: f: ;tag=pqxa29jt8v t: ;tag=c3579c1a01 i: f1d61565275f-tqgd64ng8qmq CSeq: 2 INVITE m: 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: f: ;tag=pqxa29jt8v t: ;tag=c3579c1a01 i: f1d61565275f-tqgd64ng8qmq CSeq: 2 INVITE m: 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
[SR-Users] Re: CANCEL first, then INVITE.
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:1008@10.0.0.177 SIP/2.0 v: SIP/2.0/UDP 10.0.0.117:42414;branch=z9hG4bK-dyp7uuyl7zjs;rport f: ;tag=rsxulncekf t: i: a62d14656998-uhh0lmce49oh CSeq: 2 INVITE Max-Forwards: 70 User-Agent: snomD785/10.1.159.12 m: ;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="1006",realm="10.0.0.177",nonce="ZRQu1mUULaq2rH8lPjaCtARPy4Wa7KfQ",uri="sip:1008@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: ;tag=rsxulncekf t: 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:1008@10.0.0.110:5063;alias=10.0.0.110~5063~1 SIP/2.0 Record-Route: 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: ;tag=rsxulncekf t: i: a62d14656998-uhh0lmce49oh CSeq: 2 INVITE Max-Forwards: 69 User-Agent: snomD785/10.1.159.12 m: ;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: ;tag=rsxulncekf Record-Route: t: ;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: ;tag=rsxulncekf Record-Route: t: ;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: 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: ;tag=rsxulncekf Record-Route: t: ;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: 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:1008@10.0.0.26:7066 SIP/2.0 Record-Route: 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: ;tag=rsxulncekf t: i: a62d14656998-uhh0lmce49oh CSeq: 2 INVITE Max-Forwards: 69 User-Agent: snomD785/10.1.159.12 m: ;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
[SR-Users] Re: CANCEL first, then INVITE.
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 >> 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-le...@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-le...@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-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: CANCEL first, then INVITE.
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 > 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-le...@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-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
