6 Mar
2023
6 Mar
'23
10:52 a.m.
Hi
CPE registering with TCP (or TLS).
2nd leg is UDP.
Within one transaction (INVITE to OK including all ACK and PRACK)
transport is kept as desired for both legs.
But when the B side disconnects (sending BYE, new reverse transaction),
this is sent via UDP to the A CPE which initially talked TCP and thus
ignored.
record_route() is called on each leg.
What could I be missing?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
6 Mar
6 Mar
2:14 p.m.
Hello,
On 06.03.23 10:52, Benoit Panizzon wrote:
Hi
CPE registering with TCP (or TLS).
2nd leg is UDP.
Within one transaction (INVITE to OK including all ACK and PRACK)
transport is kept as desired for both legs.
But when the B side disconnects (sending BYE, new reverse transaction),
this is sent via UDP to the A CPE which initially talked TCP and thus
ignored.
record_route() is called on each leg.
What could I be missing?
look at the Contact headers in INVITE/200ok and see if it is a match
with the r-uri in the BYE and the transport is set properly.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com
2:32 p.m.
Hi,
Check the ;transport attribute on the RURI of the BYE, and remember that the absence of an
explicit ;transport attribute means UDP by default.
-- Alex
On Mar 6, 2023, at 4:52 AM, Benoit Panizzon
<benoit.panizzon(a)imp.ch> wrote:
Hi
CPE registering with TCP (or TLS).
2nd leg is UDP.
Within one transaction (INVITE to OK including all ACK and PRACK)
transport is kept as desired for both legs.
But when the B side disconnects (sending BYE, new reverse transaction),
this is sent via UDP to the A CPE which initially talked TCP and thus
ignored.
record_route() is called on each leg.
What could I be missing?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
__________________________________________________________
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
3:10 p.m.
Hi Alex and Daniel
Thank you for the quick reply.
I have now also set double_rr = 2 but still no joy, same two RR header
are added as before.
modparam("rr", "enable_full_lr", 0)
modparam("rr", "append_fromtag", 1)
modparam("rr", "enable_double_rr", 2)
Situation, IP's and Usernames a bit mangled
CPE <TCP> Kamailio Reg <UDP> Kamailio Core <UDP> IC
CPE => Reg
INVITE sip:1111@dev-reg.example.com SIP/2.0
Via: SIP/2.0/TCP [CPEIP]:5060;branch=z9hG4bK9b3c29e0dad0e5b9
Route: <sip:[REGIP];transport=tcp;lr>
From: "John Doe" <sip:2222@dev-reg.example.com>;tag=295116bd1a873e35
To: <sip:1111@dev-reg.example.com>
Contact: <sip:2222@[CPEIP]:5060;transport=tcp>
Reg => Core
INVITE sip:1111@dev-reg.example.com SIP/2.0
Record-Route: <sip:[REGIP];r2=on;lr;ftag=295116bd1a873e35>
Record-Route: <sip:[REGIP];transport=tcp;r2=on;lr;ftag=295116bd1a873e35>
Via: SIP/2.0/UDP [REGIP];branch=z9hG4bKff2c.bdf51fa760a7fbf45d63cf2dc6149cd5.0;i=3
Via: SIP/2.0/TCP [CPEIP]:5060;branch=z9hG4bK9b3c29e0dad0e5b9
From: "John Doe" <sip:2222@dev-reg.example.com>;tag=295116bd1a873e35
To: <sip:1111@dev-reg.example.com>
Contact: <sip:2222@[CPEIP]:5060;transport=tcp>
Core => IC
INVITE sip:+41NPRN1111@[ICIP]:5060 SIP/2.0
Record-Route: <sip:[COREIP];lr;did=9fb.265>
Record-Route: <sip:[REGIP];r2=on;lr;ftag=295116bd1a873e35>
Record-Route: <sip:[REGIP];transport=tcp;r2=on;lr;ftag=295116bd1a873e35>
Via: SIP/2.0/UDP [COREIP];branch=z9hG4bKff2c.cd37a51708f805c3a86ad51b01b2ad43.0
Via: SIP/2.0/UDP [REGIP];branch=z9hG4bKff2c.bdf51fa760a7fbf45d63cf2dc6149cd5.0;i=3
Via: SIP/2.0/TCP [CPEIP]:5060;branch=z9hG4bK9b3c29e0dad0e5b9
From: "John Doe" <sip:2222@dev-reg.example.com>;tag=295116bd1a873e35
To: <sip:1111@dev-reg.example.com>
Contact: <sip:22222@[CPEIP]:5060;transport=tcp>
So what I understands, the last entry in the route set and the Contact
header state the last transport is TCP.
Omitting 180, prack, ack etc, as the don't cause a Problem. so right to BYE:
IC => CORE
BYE sip:2222@[CPEIP]:5060 SIP/2.0
Max-Forwards: 61
Route: <sip:[COREIP];lr;did=9fb.265>
Route: <sip:[REGIP];r2=on;lr;ftag=295116bd1a873e35>
Route: <sip:[REGIP];transport=tcp;r2=on;lr;ftag=295116bd1a873e35>
To: "John Doe" <sip:2222@dev-reg.examplel.com>;tag=295116bd1a873e35
From: <sip:+41NPRN1111@dev-reg.example.com>;tag=3887096572-1655837278
CSeq: 2 BYE
Via: SIP/2.0/UDP [ICIP]:5060;branch=z9hG4bKbf46cc2d5bdbf33cdb99543b438afb16
Indeed, the BYE does not specify transport=tcp, but the last entry in
the route does, so shouldn't that be used?
Core => Reg
BYE sip:2222@[CPEIP]:5060 SIP/2.0
Max-Forwards: 60
Route: <sip:[REGIP];r2=on;lr;ftag=295116bd1a873e35>
Route: <sip:[REGIP];transport=tcp;r2=on;lr;ftag=295116bd1a873e35>
To: "John Doe" <sip:2222@dev-reg.examplel.com>;tag=295116bd1a873e35
From: <sip:1111@dev-reg.example.com>;tag=3887096572-1655837278
CSeq: 2 BYE
Allow:
PUBLISH,MESSAGE,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL
Via: SIP/2.0/UDP [COREIP];branch=z9hG4bKd2cd.cc6c4cfb9e956d20b30c2c8dc4fb653d.0
Via: SIP/2.0/UDP [ICIP]:5060;branch=z9hG4bKbf46cc2d5bdbf33cdb99543b438afb16
Reg => CPE (transmitted via UDP!)
BYE sip:2222@[CPEIP]:5060 SIP/2.0
Max-Forwards: 59
To: "John Doe" <sip:2222@dev-reg.examplel.com>;tag=295116bd1a873e35
From: <sip:1111@dev-reg.example.com>;tag=3887096572-1655837278
CSeq: 2 BYE
Allow:
PUBLISH,MESSAGE,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL
Via: SIP/2.0/UDP [REGIP];branch=z9hG4bKd2cd.6a5e43e7f40c13088f744a6e8265f618.0
Via: SIP/2.0/UDP [COREIP];branch=z9hG4bKd2cd.cc6c4cfb9e956d20b30c2c8dc4fb653d.0
Via: SIP/2.0/UDP [ICIP]:5060;branch=z9hG4bKbf46cc2d5bdbf33cdb99543b438afb16
So indeed, the remote party in our IC does not specify transport=tcp in
the RURI. Does it have to do so?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
4:51 p.m.
Hello,
own record-routes are to tell neighbouring SIP nodes where/how to send
the requests within dialog to the proxy. They are not about how the
proxy sends to next hop. It could be a (record-)route added by the next
hop, if that would be another proxy, but if it is an endpoint, then the
contact address says where/how the proxy has to send it.
If your endpoint is not able to preserve and use later the URI received
in Contact, then you have to workaround it with htable or dialog or
other config operations/conditions based on SIP headers.
Cheers,
Daniel
On 06.03.23 15:10, Benoit Panizzon wrote:
Hi Alex and Daniel
Thank you for the quick reply.
I have now also set double_rr = 2 but still no joy, same two RR header
are added as before.
modparam("rr", "enable_full_lr", 0)
modparam("rr", "append_fromtag", 1)
modparam("rr", "enable_double_rr", 2)
Situation, IP's and Usernames a bit mangled
CPE <TCP> Kamailio Reg <UDP> Kamailio Core <UDP> IC
CPE => Reg
INVITE sip:1111@dev-reg.example.com SIP/2.0
Via: SIP/2.0/TCP [CPEIP]:5060;branch=z9hG4bK9b3c29e0dad0e5b9
Route: <sip:[REGIP];transport=tcp;lr>
From: "John Doe" <sip:2222@dev-reg.example.com>;tag=295116bd1a873e35
To: <sip:1111@dev-reg.example.com>
Contact: <sip:2222@[CPEIP]:5060;transport=tcp>
Reg => Core
INVITE sip:1111@dev-reg.example.com SIP/2.0
Record-Route: <sip:[REGIP];r2=on;lr;ftag=295116bd1a873e35>
Record-Route: <sip:[REGIP];transport=tcp;r2=on;lr;ftag=295116bd1a873e35>
Via: SIP/2.0/UDP [REGIP];branch=z9hG4bKff2c.bdf51fa760a7fbf45d63cf2dc6149cd5.0;i=3
Via: SIP/2.0/TCP [CPEIP]:5060;branch=z9hG4bK9b3c29e0dad0e5b9
From: "John Doe" <sip:2222@dev-reg.example.com>;tag=295116bd1a873e35
To: <sip:1111@dev-reg.example.com>
Contact: <sip:2222@[CPEIP]:5060;transport=tcp>
Core => IC
INVITE sip:+41NPRN1111@[ICIP]:5060 SIP/2.0
Record-Route: <sip:[COREIP];lr;did=9fb.265>
Record-Route: <sip:[REGIP];r2=on;lr;ftag=295116bd1a873e35>
Record-Route: <sip:[REGIP];transport=tcp;r2=on;lr;ftag=295116bd1a873e35>
Via: SIP/2.0/UDP [COREIP];branch=z9hG4bKff2c.cd37a51708f805c3a86ad51b01b2ad43.0
Via: SIP/2.0/UDP [REGIP];branch=z9hG4bKff2c.bdf51fa760a7fbf45d63cf2dc6149cd5.0;i=3
Via: SIP/2.0/TCP [CPEIP]:5060;branch=z9hG4bK9b3c29e0dad0e5b9
From: "John Doe" <sip:2222@dev-reg.example.com>;tag=295116bd1a873e35
To: <sip:1111@dev-reg.example.com>
Contact: <sip:22222@[CPEIP]:5060;transport=tcp>
So what I understands, the last entry in the route set and the Contact
header state the last transport is TCP.
Omitting 180, prack, ack etc, as the don't cause a Problem. so right to BYE:
IC => CORE
BYE sip:2222@[CPEIP]:5060 SIP/2.0
Max-Forwards: 61
Route: <sip:[COREIP];lr;did=9fb.265>
Route: <sip:[REGIP];r2=on;lr;ftag=295116bd1a873e35>
Route: <sip:[REGIP];transport=tcp;r2=on;lr;ftag=295116bd1a873e35>
To: "John Doe" <sip:2222@dev-reg.examplel.com>;tag=295116bd1a873e35
From: <sip:+41NPRN1111@dev-reg.example.com>;tag=3887096572-1655837278
CSeq: 2 BYE
Via: SIP/2.0/UDP [ICIP]:5060;branch=z9hG4bKbf46cc2d5bdbf33cdb99543b438afb16
Indeed, the BYE does not specify transport=tcp, but the last entry in
the route does, so shouldn't that be used?
Core => Reg
BYE sip:2222@[CPEIP]:5060 SIP/2.0
Max-Forwards: 60
Route: <sip:[REGIP];r2=on;lr;ftag=295116bd1a873e35>
Route: <sip:[REGIP];transport=tcp;r2=on;lr;ftag=295116bd1a873e35>
To: "John Doe" <sip:2222@dev-reg.examplel.com>;tag=295116bd1a873e35
From: <sip:1111@dev-reg.example.com>;tag=3887096572-1655837278
CSeq: 2 BYE
Allow:
PUBLISH,MESSAGE,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL
Via: SIP/2.0/UDP [COREIP];branch=z9hG4bKd2cd.cc6c4cfb9e956d20b30c2c8dc4fb653d.0
Via: SIP/2.0/UDP [ICIP]:5060;branch=z9hG4bKbf46cc2d5bdbf33cdb99543b438afb16
Reg => CPE (transmitted via UDP!)
BYE sip:2222@[CPEIP]:5060 SIP/2.0
Max-Forwards: 59
To: "John Doe" <sip:2222@dev-reg.examplel.com>;tag=295116bd1a873e35
From: <sip:1111@dev-reg.example.com>;tag=3887096572-1655837278
CSeq: 2 BYE
Allow:
PUBLISH,MESSAGE,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL
Via: SIP/2.0/UDP [REGIP];branch=z9hG4bKd2cd.6a5e43e7f40c13088f744a6e8265f618.0
Via: SIP/2.0/UDP [COREIP];branch=z9hG4bKd2cd.cc6c4cfb9e956d20b30c2c8dc4fb653d.0
Via: SIP/2.0/UDP [ICIP]:5060;branch=z9hG4bKbf46cc2d5bdbf33cdb99543b438afb16
So indeed, the remote party in our IC does not specify transport=tcp in
the RURI. Does it have to do so?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
__________________________________________________________
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 -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com
9 Mar
9 Mar
3:37 p.m.
New subject: RFC specifying use of transport= attribute in Contact and RURI (Re: Re: New 'reverse' transaction not using correct transport protocol)
Hi Daniel, Alex and all
I'm having an argument with the Vendor of our SBC towards IC carriers.
According to $vendor tech, if the SIP Message was received via UDP, the
transport= attribute of the Contact Header has no meaning and therefore
the RURI of a following transaction (like BYE) will not contain a
transport attribute as the reply is sent via UDP.
This of course breaks communication CPE behind a kamailio proxy which
are connected via TCP or TLS.
I've been looking through RFC3261 and I find various examples how the
transport attribute can be used.
But I fail to find, that a transport received in the Contact header
MUST be re-used in the RURI of subsequent transactions within one
dialogue.
From my point of view, this is logical and this is how various devices
I have tested operate. But with a commercial vendor, if it's not in the
RFC it's no Bug and won't be fixed... Does anyone know in which section
(or maybe other RFC) this is covered?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
10 Mar
10 Mar
5:10 p.m.
New subject: RFC specifying use of transport= attribute in Contact and RURI (Re: Re: New 'reverse' transaction not using correct transport protocol)
12.2.1.2 Processing the Responses
The UAC will receive responses to the request from the transaction
layer. If the client transaction returns a timeout, this is treated
as a 408 (Request Timeout) response.
The behavior of a UAC that receives a 3xx response for a request sent
within a dialog is the same as if the request had been sent outside a
dialog. This behavior is described in Section 8.1.3.4.
Note, however, that when the UAC tries alternative locations, it
still uses the route set for the dialog to build the Route header
of the request.
When a UAC receives a 2xx response to a target refresh request, it
MUST replace the dialog's remote target URI with the URI from the
Contact header field in that response, if present.
https://www.rfc-editor.org/rfc/rfc3261#section-12.2.1.2
20.10 Contact
A Contact header field value provides a URI whose meaning depends on
the type of request or response it is in.
A Contact header field value can contain a display name, a URI with
URI parameters, and header parameters.
This document defines the Contact parameters "q" and "expires".
These parameters are only used when the Contact is present in a
REGISTER request or response, or in a 3xx response. Additional
parameters may be defined in other specifications.
When the header field value contains a display name, the URI
including all URI parameters is enclosed in "<" and ">". If
no "<"
and ">" are present, all parameters after the URI are header
parameters, not URI parameters.
https://www.rfc-editor.org/rfc/rfc3261#section-20.10
On Thu, Mar 9, 2023 at 6:00 PM Benoit Panizzon <benoit.panizzon(a)imp.ch>
wrote:
Hi Daniel, Alex and all
I'm having an argument with the Vendor of our SBC towards IC carriers.
According to $vendor tech, if the SIP Message was received via UDP, the
transport= attribute of the Contact Header has no meaning and therefore
the RURI of a following transaction (like BYE) will not contain a
transport attribute as the reply is sent via UDP.
This of course breaks communication CPE behind a kamailio proxy which
are connected via TCP or TLS.
I've been looking through RFC3261 and I find various examples how the
transport attribute can be used.
But I fail to find, that a transport received in the Contact header
MUST be re-used in the RURI of subsequent transactions within one
dialogue.
From my point of view, this is logical and this is how various devices
I have tested operate. But with a commercial vendor, if it's not in the
RFC it's no Bug and won't be fixed... Does anyone know in which section
(or maybe other RFC) this is covered?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
__________________________________________________________
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:
406
days inactive
410
days old
6 comments
4 participants
participants (4)
-
Alex Balashov -
Benoit Panizzon -
Daniel-Constantin Mierla -
Sergey Safarov