General Lee schrieb:
One answer may be in the SDP.
the OK from the kamailio to the client reads v=0. o=103 2114479936 0 IN IP4 192.168.0.151. s=-. i=Dylogic Mirial 7.0.7. c=IN IP4 69.35.104.179. b=AS:256. t=0 0. m=audio 42248 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=x-mpdp:192.168.0.151:49620. m=video 41044 RTP/AVP 96 34. a=rtpmap:96 H263-1998/90000. a=fmtp:96 CIF=1; QCIF=1; D=1; F=1; I=1; J=1; L=1; S=1; T=1. a=rtpmap:34 H263/90000. a=fmtp:34 CIF=1; QCIF=1. a=x-mpdp:192.168.0.151:49622. a=nortpproxy:yes.
and the ACK reads
v=0. o=GateWay 1 0 IN IP4 69.35.15.51. s=SipCall. c=IN IP4 69.35.104.179. t=0 0. a=sendrecv. m=audio 42248 RTP/AVP 0. a=sendrecv. a=rtpmap:0 PCMU/8000/1. m=video 41044 RTP/AVP 34. a=rtpmap:34 H263/90000/1. a=nortpproxy:yes.
So my question is ... Why is RTP Proxy telling both clients to talk to it on the same port for audio and again for video?? You can see in the fast-connect version how the two ports are different.
Here is an example of the callee being setup as the caller.
I just took a look at the code and there is a bug in nathelper when using "s" flag on ACK.
Probably rtpproxy_offer/answer should be used:
static int 2417 force_rtp_proxy2_f(struct sip_msg *msg, char *param1, char *param2) 2418 { 2419 int offer; 2420 2421 if (msg->first_line.type == SIP_REQUEST && 2422 msg->first_line.u.request.method_value == METHOD_INVITE) { 2423 offer = 1; 2424 } else if (msg->first_line.type == SIP_REPLY) { 2425 offer = 0; 2426 } else { 2427 return -1; 2428 } 2429 2430 return force_rtp_proxy(msg, param1, param2, offer); 2431 }
if you remove the METHOD_INVITE condition in line 2422 it should work. (make sure you never call force_rtpproxy for other methods)
regards klaus