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:[email protected] SIP/2.0
> Via: SIP/2.0/TCP [CPEIP]:5060;branch=z9hG4bK9b3c29e0dad0e5b9
> Route: <sip:[REGIP];transport=tcp;lr>
> From: "John Doe" <sip:[email protected]>;tag=295116bd1a873e35
> To: <sip:[email protected]>
> Contact: <sip:2222@[CPEIP]:5060;transport=tcp>
>
> Reg => Core
>
> INVITE sip:[email protected] 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:[email protected]>;tag=295116bd1a873e35
> To: <sip:[email protected]>
> 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:[email protected]>;tag=295116bd1a873e35
> To: <sip:[email protected]>
> 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:[email protected]>;tag=295116bd1a873e35
> From: <sip:[email protected]>;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:[email protected]>;tag=295116bd1a873e35
> From: <sip:[email protected]>;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:[email protected]>;tag=295116bd1a873e35
> From: <sip:[email protected]>;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 [email protected]
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
--
Daniel-Constantin Mierla -- 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
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
