Hello,
I have been having an issue using kamailio to load balance to a SIP/MRCP server. I believe that the issue actually lies with the reply being sent from the final recipient, but I wanted to be sure that I understood the problem and to see if there were any possible solutions within Kamailio.
I am using the dispatcher module to dispatch SIP INVITES to media resources, in this case I am just using a single host in a single dispatcher group. The configuration that I have has worked just fine for other SIP/MRCP servers, which is why I think the issue is with this target in particular.
The INVITE is routed correctly and contains the headers that it should. The invite comes originally from a Freeswitch, arrives at Kamailio, who should then dispatch to a host in the group.
x.x.x.x:4901 is Kamailio x.x.x.x:8090 is Freeswitch y.y.y.y:8000 is the final target
This is the invite, as received by the final target after dispatched via Kamailio
INVITE sip: x.x.x.x:4901 SIP/2.0 Record-Route: <sip: x.x.x.x:4901;transport=tcp;lr> Via: SIP/2.0/TCP x.x.x.x:4901;branch=z9hG4bK3a9a.7f9a4b588cd75108cfea9a2bd9ffa829.0;i=3 Via: SIP/2.0/TCP x.x.x.x:8090;branch=z9hG4bKStXp06Sv7jU7S Max-Forwards: 69 From: <sip: x.x.x.x:8090>;tag=4gHgNcNUDjvFQ To: <sip: x.x.x.x:4901> Call-ID: 6f2a0e9c-3f9e-1238-2aa9-005056854777 CSeq: 8692231 INVITE User-Agent: tts Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel Content-Type: application/sdp Content-Disposition: session Content-Length: 281
v=0 o=IPSoft 3367790083977298880 2789991278648035021 IN IP4 x.x.x.x s=- c=IN IP4 x.x.x.x t=0 0 m=application 9 TCP/MRCPv2 1 a=setup:active a=connection:existing a=resource:speechsynth a=cmid:1 m=audio 32038 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly a=mid:1
The reply that the server sends back appears to be missing a second Via header, which is preventing Kamailio for routing it correctly (based on the error message from core/forward.c)
This is the reply sent by the target destination
SIP/2.0 200 OK Via: SIP/2.0/TCP x.x.x.x:8090;branch=z9hG4bKStXp06Sv7jU7S To: <sip: x.x.x.x:4901>;tag=ndszib3k From: <sip: x.x.x.x:8090>;tag=4gHgNcNUDjvFQ Call-ID: 6f2a0e9c-3f9e-1238-2aa9-005056854777 CSeq: 8692231 INVITE Contact: "Voiceware MRCP Server" <sip:vwmrcp@ y.y.y.y:8000;transport=tcp> Content-Type: application/sdp Content-Length: 324
v=0 o=- 1566492047 1566492047 IN IP4 y.y.y.y s=Voiceware MRCP Server 2.15.0.7. Dec 28 2018 c=IN IP4 y.y.y.y t=0 0 m=application 8002 TCP/MRCPv2 1 a=channel:12951125463@speechsynth a=connection:new a=setup:passive a=cmid:1 m=audio 30158 RTP/AVP 0 a=rtpmap:0 pcmu/8000 a=sendonly a=ptime:20 a=mid:1
It is correct that there should still be a 2nd Via header in the 200 OK reply from the target host, right?
If so, is there anything else that can be done in Kamailio to handle this, or is this mrcp server simply not complying properly with SIP?
There’s no funky natting between these hosts or anything like that.
Thanks in advance!
Hello Ryan,
the replies are forwared with the Via header. So if there is no second Via header in the reply from the MRCP server, Kamailio can't properly route this. So this looks like an issue with the MRCP.
Have a look to this example for a somewhat similar setup that describe it in detail: https://tools.ietf.org/html/rfc3665#section-3.2
Cheers,
Henning
Am 23.08.19 um 23:25 schrieb Ryan McEvoy: Hello,
I have been having an issue using kamailio to load balance to a SIP/MRCP server. I believe that the issue actually lies with the reply being sent from the final recipient, but I wanted to be sure that I understood the problem and to see if there were any possible solutions within Kamailio.
I am using the dispatcher module to dispatch SIP INVITES to media resources, in this case I am just using a single host in a single dispatcher group. The configuration that I have has worked just fine for other SIP/MRCP servers, which is why I think the issue is with this target in particular.
The INVITE is routed correctly and contains the headers that it should. The invite comes originally from a Freeswitch, arrives at Kamailio, who should then dispatch to a host in the group.
x.x.x.x:4901 is Kamailio x.x.x.x:8090 is Freeswitch y.y.y.y:8000 is the final target
This is the invite, as received by the final target after dispatched via Kamailio
INVITE sip: x.x.x.x:4901 SIP/2.0 Record-Route: <sip: x.x.x.x:4901;transport=tcp;lr> Via: SIP/2.0/TCP x.x.x.x:4901;branch=z9hG4bK3a9a.7f9a4b588cd75108cfea9a2bd9ffa829.0;i=3 Via: SIP/2.0/TCP x.x.x.x:8090;branch=z9hG4bKStXp06Sv7jU7S Max-Forwards: 69 From: <sip: x.x.x.x:8090>;tag=4gHgNcNUDjvFQ To: <sip: x.x.x.x:4901> Call-ID: 6f2a0e9c-3f9e-1238-2aa9-005056854777 CSeq: 8692231 INVITE User-Agent: tts Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel Content-Type: application/sdp Content-Disposition: session Content-Length: 281
v=0 o=IPSoft 3367790083977298880 2789991278648035021 IN IP4 x.x.x.x s=- c=IN IP4 x.x.x.x t=0 0 m=application 9 TCP/MRCPv2 1 a=setup:active a=connection:existing a=resource:speechsynth a=cmid:1 m=audio 32038 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly a=mid:1
The reply that the server sends back appears to be missing a second Via header, which is preventing Kamailio for routing it correctly (based on the error message from core/forward.c)
This is the reply sent by the target destination
SIP/2.0 200 OK Via: SIP/2.0/TCP x.x.x.x:8090;branch=z9hG4bKStXp06Sv7jU7S To: <sip: x.x.x.x:4901>;tag=ndszib3k From: <sip: x.x.x.x:8090>;tag=4gHgNcNUDjvFQ Call-ID: 6f2a0e9c-3f9e-1238-2aa9-005056854777 CSeq: 8692231 INVITE Contact: "Voiceware MRCP Server" <sip:vwmrcp@ y.y.y.y:8000;transport=tcp>mailto:sip:vwmrcp@y.y.y.y:8000;transport=tcp Content-Type: application/sdp Content-Length: 324
v=0 o=- 1566492047 1566492047 IN IP4 y.y.y.y s=Voiceware MRCP Server 2.15.0.7. Dec 28 2018 c=IN IP4 y.y.y.y t=0 0 m=application 8002 TCP/MRCPv2 1 a=channel:12951125463@speechsynth a=connection:new a=setup:passive a=cmid:1 m=audio 30158 RTP/AVP 0 a=rtpmap:0 pcmu/8000 a=sendonly a=ptime:20 a=mid:1
It is correct that there should still be a 2nd Via header in the 200 OK reply from the target host, right?
If so, is there anything else that can be done in Kamailio to handle this, or is this mrcp server simply not complying properly with SIP?
There’s no funky natting between these hosts or anything like that.
Thanks in advance!
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services