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.org<mailto: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