Hello,
I work on interconnecting an old SER version with Kamailio.
When a BYE is sent by the old SER, the "if (loose_route)" instruction returns false and then a "404 Not here" is sent. So the BYE is not relay to the UA.
If the BYE is sent by Kamailio, no problem.
Here are the BYE headers received by Kamailio:
Record-Route: sip:OLD_SER_IP_ADDRESS;ftag=e97b7b77c5a3a9cc;lr=on
Via: SIP/2.0/UDP OLD_SER_IP_ADDRESS;branch=z9hG4bKc9e5.3cbad207.0
Via: SIP/2.0/UDP UA_IP_ADDRESS_CONNECTED_TO_OLD_SER:5060;rport=5060;branch=z9hG4bK1fbe0a49fe3 44e6af1efd45b74305a9a
Route: sip:KAMAILIO_IP_ADDRESS;lr=on
I looked at the RR module documentation and it's clearly said that "The loose_route function analyzes the Route: headers in the requests. [.]If a Route: header is found, the function returns 1 and behaves as described in section 16.12 of RFC 3261.".
Someone has an idea?
Regards,
Igor.
--- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
Igor,
Can you provide the full BYE message, not just some of the headers?
Thanks,
-- Alex
Hello,
you have to give all the BYE -- the best is to send from the first INVITE to the last BYE, because it matters how the record-route are built for INVITE.
I suspect that the BYE comes with r-uri having kamailio address, if the old ser does fix natted contact (which should not do in this case).
Cheers, Daniel
On 11/20/13 3:03 PM, Igor Potjevlesch wrote:
Hello,
Thank you for your reply. Indeed, I think that R-URI contains the kamailio address.
Here is the full trace :
Frame 35: 1015 bytes on wire (8120 bits), 1015 bytes captured (8120 bits)
Ethernet II, Src: b0:fa:eb:fc:9a:40 (b0:fa:eb:fc:9a:40), Dst: Broadcom_6c:77:94 (00:10:18:6c:77:94)
Internet Protocol Version 4, Src: IP_ADDRESS_KAMAILIO (IP_ADDRESS_KAMAILIO), Dst: IP_ADDRESS_OLD_SER (IP_ADDRESS_OLD_SER)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: INVITE sip:101@sip.fqdn SIP/2.0
Message Header
Record-Route: sip:IP_ADDRESS_KAMAILIO;lr=on
Via: SIP/2.0/UDP IP_ADDRESS_KAMAILIO;branch=z9hG4bKb9e5.f4f14df5.0
Via: SIP/2.0/UDP IP_END_USER:5060;rport=5060;branch=z9hG4bK-dfc0fcaa
From: "102" sip:102@sip.fqdn;tag=806b7e8f1bbefb72o0
To: sip:101@sip.fqdn
Call-ID: e2d6ce93-527a4b3e@192.168.10.41
CSeq: 102 INVITE
Max-Forwards: 16
Contact: "102" sip:102@IP_END_USER:5060
Expires: 240
User-Agent: Cisco/SPA525G2-7.5.2a
Content-Length: 314
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE
Supported: replaces
Content-Type: application/sdp
Message Body
Frame 40: 681 bytes on wire (5448 bits), 681 bytes captured (5448 bits)
Ethernet II, Src: Broadcom_6c:77:94 (00:10:18:6c:77:94), Dst: b0:fa:eb:fc:9a:40 (b0:fa:eb:fc:9a:40)
Internet Protocol Version 4, Src: IP_ADDRESS_OLD_SER (IP_ADDRESS_OLD_SER), Dst: IP_ADDRESS_KAMAILIO (IP_ADDRESS_KAMAILIO)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 180 Ringing
Message Header
Via: SIP/2.0/UDP IP_ADDRESS_KAMAILIO;rport=5060;branch=z9hG4bKb9e5.f4f14df5.0
Via: SIP/2.0/UDP IP_END_USER:5060;rport=5060;branch=z9hG4bK-dfc0fcaa
Record-Route: sip:IP_ADDRESS_OLD_SER;ftag=806b7e8f1bbefb72o0;lr=on
Record-Route: sip:IP_ADDRESS_KAMAILIO;lr=on
From: "102" sip:102@sip.fqdn;tag=806b7e8f1bbefb72o0
To: sip:101@sip.fqdn;tag=e97b7b77c5a3a9cc
Call-ID: e2d6ce93-527a4b3e@192.168.10.41
CSeq: 102 INVITE
Contact: "Extn1074" sip:101@10.141.0.21:5060;transport=udp
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE
Supported: timer
Content-Length: 0
Frame 149: 932 bytes on wire (7456 bits), 932 bytes captured (7456 bits)
Ethernet II, Src: Broadcom_6c:77:94 (00:10:18:6c:77:94), Dst: b0:fa:eb:fc:9a:40 (b0:fa:eb:fc:9a:40)
Internet Protocol Version 4, Src: IP_ADDRESS_OLD_SER (IP_ADDRESS_OLD_SER), Dst: IP_ADDRESS_KAMAILIO (IP_ADDRESS_KAMAILIO)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 Ok
Message Header
Via: SIP/2.0/UDP IP_ADDRESS_KAMAILIO;rport=5060;branch=z9hG4bKb9e5.f4f14df5.0
Via: SIP/2.0/UDP IP_END_USER:5060;rport=5060;branch=z9hG4bK-dfc0fcaa
Record-Route: sip:IP_ADDRESS_OLD_SER;ftag=806b7e8f1bbefb72o0;lr=on
Record-Route: sip:IP_ADDRESS_KAMAILIO;lr=on
From: "102" sip:102@sip.fqdn;tag=806b7e8f1bbefb72o0
To: sip:101@sip.fqdn;tag=e97b7b77c5a3a9cc
Call-ID: e2d6ce93-527a4b3e@192.168.10.41
CSeq: 102 INVITE
Contact: "Extn1074" sip:101@10.141.0.21:5060;transport=udp
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE
Supported: timer
Content-Type: application/sdp
Content-Length: 223
Message Body
Frame 150: 817 bytes on wire (6536 bits), 817 bytes captured (6536 bits)
Ethernet II, Src: b0:fa:eb:fc:9a:40 (b0:fa:eb:fc:9a:40), Dst: Broadcom_6c:77:94 (00:10:18:6c:77:94)
Internet Protocol Version 4, Src: IP_ADDRESS_KAMAILIO (IP_ADDRESS_KAMAILIO), Dst: IP_ADDRESS_OLD_SER (IP_ADDRESS_OLD_SER)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: ACK sip:101@10.141.0.21:5060;transport=udp SIP/2.0
Message Header
Via: SIP/2.0/UDP IP_ADDRESS_KAMAILIO;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/UDP IP_END_USER:5060;rport=5060;branch=z9hG4bK-2fac85aa
From: "102" sip:102@sip.fqdn;tag=806b7e8f1bbefb72o0
To: sip:101@sip.fqdn;tag=e97b7b77c5a3a9cc
Call-ID: e2d6ce93-527a4b3e@192.168.10.41
CSeq: 102 ACK
Max-Forwards: 16
Route: sip:IP_ADDRESS_OLD_SER;ftag=806b7e8f1bbefb72o0;lr=on
Proxy-Authorization: Digest username="102",realm="sip.fqdn",nonce="Uoyii1KMoV+WyB1HA74q80A/4nYiA8jL",uri ="sip:101@sip.fqdn",algorithm=MD5,response="5ee662c87271f39b9e6eccb9bd0b6b59 "
Contact: "102" sip:102@IP_END_USER:5060
User-Agent: Cisco/SPA525G2-7.5.2a
Content-Length: 0
Frame 1326: 737 bytes on wire (5896 bits), 737 bytes captured (5896 bits)
Ethernet II, Src: Broadcom_6c:77:94 (00:10:18:6c:77:94), Dst: b0:fa:eb:fc:9a:40 (b0:fa:eb:fc:9a:40)
Internet Protocol Version 4, Src: IP_ADDRESS_OLD_SER (IP_ADDRESS_OLD_SER), Dst: IP_ADDRESS_KAMAILIO (IP_ADDRESS_KAMAILIO)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: BYE sip:102@IP_ADDRESS_KAMAILIO:5060 SIP/2.0
Message Header
Record-Route: sip:IP_ADDRESS_OLD_SER;ftag=e97b7b77c5a3a9cc;lr=on
Via: SIP/2.0/UDP IP_ADDRESS_OLD_SER;branch=z9hG4bKc9e5.3cbad207.0
Via: SIP/2.0/UDP 10.141.0.21:5060;rport=5060;branch=z9hG4bK1fbe0a49fe344e6af1efd45b74305a9a
Route: sip:IP_ADDRESS_KAMAILIO;lr=on
From: "101" sip:101@sip.fqdn;tag=e97b7b77c5a3a9cc
To: "102" sip:102@sip.fqdn;tag=806b7e8f1bbefb72o0
Call-ID: e2d6ce93-527a4b3e@192.168.10.41
CSeq: 103 BYE
Contact: "Extn1074" sip:101@10.141.0.21:5060;transport=udp
Max-Forwards: 16
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE
Supported: timer
Content-Length: 0
Frame 1328: 478 bytes on wire (3824 bits), 478 bytes captured (3824 bits)
Ethernet II, Src: b0:fa:eb:fc:9a:40 (b0:fa:eb:fc:9a:40), Dst: Broadcom_6c:77:94 (00:10:18:6c:77:94)
Internet Protocol Version 4, Src: IP_ADDRESS_KAMAILIO (IP_ADDRESS_KAMAILIO), Dst: IP_ADDRESS_OLD_SER (IP_ADDRESS_OLD_SER)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 404 Not here
Message Header
Via: SIP/2.0/UDP IP_ADDRESS_OLD_SER;rport=5060;branch=z9hG4bKc9e5.3cbad207.0
Via: SIP/2.0/UDP 10.141.0.21:5060;rport=5060;branch=z9hG4bK1fbe0a49fe344e6af1efd45b74305a9a
From: "101" sip:101@sip.fqdn;tag=e97b7b77c5a3a9cc
To: "102" sip:102@sip.fqdn;tag=806b7e8f1bbefb72o0
Call-ID: e2d6ce93-527a4b3e@192.168.10.41
CSeq: 103 BYE
Server: Kamailio (2.0)
Content-Length: 0
Regards,
Igor.
De : sr-users-bounces@lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] De la part de Daniel-Constantin Mierla Envoyé : mercredi 20 novembre 2013 16:42 À : Kamailio (SER) - Users Mailing List Objet : Re: [SR-Users] Problem with loose_route for a BYE
Hello,
you have to give all the BYE -- the best is to send from the first INVITE to the last BYE, because it matters how the record-route are built for INVITE.
I suspect that the BYE comes with r-uri having kamailio address, if the old ser does fix natted contact (which should not do in this case).
Cheers, Daniel
On 11/20/13 3:03 PM, Igor Potjevlesch wrote:
Hello,
I work on interconnecting an old SER version with Kamailio.
When a BYE is sent by the old SER, the if (loose_route) instruction returns false and then a 404 Not here is sent. So the BYE is not relay to the UA.
If the BYE is sent by Kamailio, no problem.
Here are the BYE headers received by Kamailio:
Record-Route: sip:OLD_SER_IP_ADDRESS;ftag=e97b7b77c5a3a9cc;lr=on
Via: SIP/2.0/UDP OLD_SER_IP_ADDRESS;branch=z9hG4bKc9e5.3cbad207.0
Via: SIP/2.0/UDP UA_IP_ADDRESS_CONNECTED_TO_OLD_SER:5060;rport=5060;branch=z9hG4bK1fbe0a49fe3 44e6af1efd45b74305a9a
Route: sip:KAMAILIO_IP_ADDRESS;lr=on
I looked at the RR module documentation and its clearly said that The loose_route function analyzes the Route: headers in the requests. [ ]If a Route: header is found, the function returns 1 and behaves as described in section 16.12 of RFC 3261..
Someone has an idea?
Regards,
Igor.
_____
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! http://www.avast.com/ est active.
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 11/20/13 6:10 PM, Igor Potjevlesch wrote:
The old ser should not do fix_nated_contact() for traffic comming from kamailio. It is not in the position to figure out the address of the nat router. That is done by kamailio (which should use anyhow add_contact_alias(), because it is a better alternative for nat fixing).
Cheers, Daniel
[...]
Thank you Daniel for your analyse. Its strange, because theres no NAT.
We force the RTPProxy in order to bypass routing issue in this call-flow, but both platform are reachable with public IP address.
I will look at the old SER and see why he does fix_nated_contact().
Regards,
Igor.
De : sr-users-bounces@lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] De la part de Daniel-Constantin Mierla Envoyé : mercredi 20 novembre 2013 22:37 À : Kamailio (SER) - Users Mailing List Objet : Re: [SR-Users] Problem with loose_route for a BYE
On 11/20/13 6:10 PM, Igor Potjevlesch wrote:
Hello,
Thank you for your reply. Indeed, I think that R-URI contains the kamailio address.
The old ser should not do fix_nated_contact() for traffic comming from kamailio. It is not in the position to figure out the address of the nat router. That is done by kamailio (which should use anyhow add_contact_alias(), because it is a better alternative for nat fixing).
Cheers, Daniel
[...]
Hello Daniel,
You were right. Thank you!
Regards,
Igor.
De : sr-users-bounces@lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] De la part de Daniel-Constantin Mierla Envoyé : mercredi 20 novembre 2013 22:37 À : Kamailio (SER) - Users Mailing List Objet : Re: [SR-Users] Problem with loose_route for a BYE
On 11/20/13 6:10 PM, Igor Potjevlesch wrote:
Hello,
Thank you for your reply. Indeed, I think that R-URI contains the kamailio address.
The old ser should not do fix_nated_contact() for traffic comming from kamailio. It is not in the position to figure out the address of the nat router. That is done by kamailio (which should use anyhow add_contact_alias(), because it is a better alternative for nat fixing).
Cheers, Daniel
[...]
-
Alex Balashov -
Daniel-Constantin Mierla -
Igor Potjevlesch