4 Nov
2009
4 Nov
'09
8:21 a.m.
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