Hmmm..have you changed the UACs on both side or at least the one that is problematic, like Juha said.
In the codec negotiation I see a=rtpmap:18 G729/8000 from pjmedia and a=rtpmap:18 G729/8000*/1* from VoIPSip/Switch I'm not sure that this channel info plays much role here because according to rfc it could be omitted if its 1 and no extra params are in the string. But I don't know if this could cause the other UAC to behave abnormally. you can also confirm if this is Server side issue or UAC side issue by taking a full size tcpdump on ther server for this particular call and hear the call using wireshark. A faulty client side behaviour can be identified if the audio on both sides is ok on server. On Mon, Oct 10, 2011 at 2:18 AM, Austin Einter <austin.ein...@gmail.com>wrote: > Hi All > Thanks for your kind answer. > > The call flow looks as below > I have two doubts here > > 1. My UA is just behind the Modem, and in Kamailio config file I have > enabled WITH_NAT, will this lead to any kind of problem > > 2. In kamailio proxy I am using force_rtp_proxy and unforce_rtp_proxy > instead of rtpproxy_offer/rtpproxy_answer. Not sure whats the corresponding > api for unforce_rtp_proxy. > will this lead to any issues. > > Regards > Austin. > > INVITE sip:919731573290@134.121.32.130:5060 SIP/2.0 > Via: SIP/2.0/UDP 192.168.1.2:53489 > ;rport;branch=z9hG4bKPj0052793130024dda88418cf7a392b7ae > Max-Forwards: 70 > From: sip:austin@134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46 > To: sip:919731573290@134.121.32.130 > Contact: <sip:austin@192.168.1.2:53489;ob> > Call-ID: b637fa62393a45a0a58633c1a8f43a86 > CSeq: 14417 INVITE > Route: <sip:134.33.8.138:5060;lr> > Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, > MESSAGE, OPTIONS > Supported: replaces, 100rel, timer, norefersub > Session-Expires: 1800 > Min-SE: 90 > User-Agent: VoIP Client v1.01 > Proxy-Authorization: Digest username="austin", realm="VoipSwitch", > nonce="131819433109160428210053141040", uri=" > sip:919731573290@134.121.32.130:5060", > response="935c3130fe07e2413ccf127d5fb6b9d1" > Content-Type: application/sdp > Content-Length: 271 > > v=0 > o=- 3527202931 3527202931 IN IP4 192.168.1.2 > s=pjmedia > c=IN IP4 192.168.1.2 > t=0 0 > a=X-nat:0 > m=audio 4000 RTP/AVP 18 4 96 > a=rtcp:4001 IN IP4 192.168.1.2 > a=rtpmap:18 G729/8000 > a=rtpmap:4 G723/8000 > a=sendrecv > a=rtpmap:96 telephone-event/8000 > a=fmtp:96 0-15 > > SIP/2.0 100 trying > Via: SIP/2.0/UDP 192.168.1.2:53489 > ;rport=13341;branch=z9hG4bKPj0052793130024dda88418cf7a392b7ae;received=122.178.237.67 > From: sip:austin@134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46 > To: sip:919731573290@134.121.32.130 > Call-ID: b637fa62393a45a0a58633c1a8f43a86 > CSeq: 14417 INVITE > Server: kamailio (3.1.5 (i386/linux)) > Content-Length: 0 > > > SIP/2.0 183 Session Progress > CSeq: 14417 INVITE > Via: SIP/2.0/UDP 192.168.1.2:53489 > ;branch=z9hG4bKPj0052793130024dda88418cf7a392b7ae > From: sip:austin@134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46 > Call-ID: b637fa62393a45a0a58633c1a8f43a86 > To: sip:919731573290@134.121.32.130;tag=09100511163117092280006157 > Contact: <sip:134.121.32.130:5060;transport=udp> > Content-Type: application/sdp > Content-Length: 241 > Record-Route: <sip:134.33.8.138;lr=on;nat=yes> > > v=0 > o=VoipSwitch 6156 7156 IN IP4 134.33.8.138 > s=VoipSIP > i=Audio Session > c=IN IP4 134.33.8.138 > t=0 0 > m=audio 46976 RTP/AVP 18 96 > a=rtpmap:18 G729/8000/1 > a=rtpmap:96 telephone-event/8000 > a=fmtp:96 0-15 > a=sendrecv > a=nortpproxy:yes > > SIP/2.0 200 OK > CSeq: 14417 INVITE > Via: SIP/2.0/UDP 192.168.1.2:53489 > ;branch=z9hG4bKPj0052793130024dda88418cf7a392b7ae > From: sip:austin@134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46 > Call-ID: b637fa62393a45a0a58633c1a8f43a86 > To: sip:919731573290@134.121.32.130;tag=09100511163117092280006157 > Contact: <sip:134.121.32.130:5060;transport=udp> > Content-Type: application/sdp > Content-Length: 241 > Record-Route: <sip:134.33.8.138;lr=on;nat=yes> > > v=0 > o=VoipSwitch 6156 7156 IN IP4 134.33.8.138 > s=VoipSIP > i=Audio Session > c=IN IP4 134.33.8.138 > t=0 0 > m=audio 46976 RTP/AVP 18 96 > a=rtpmap:18 G729/8000/1 > a=rtpmap:96 telephone-event/8000 > a=fmtp:96 0-15 > a=sendrecv > a=nortpproxy:yes > > ACK sip:134.121.32.130:5060;transport=udp SIP/2.0 > Via: SIP/2.0/UDP 192.168.1.2:53489 > ;rport;branch=z9hG4bKPj73092b1de9aa4d4498adac484efacfda > Max-Forwards: 70 > From: sip:austin@134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46 > To: sip:919731573290@134.121.32.130;tag=09100511163117092280006157 > Call-ID: b637fa62393a45a0a58633c1a8f43a86 > CSeq: 14417 ACK > Route: <sip:134.33.8.138;lr;nat=yes> > Content-Length: 0 > > > BYE sip:austin@122.178.237.67:13341;ob SIP/2.0 > Max-Forwards: 10 > CSeq: 1 BYE > Via: SIP/2.0/UDP 134.33.8.138;branch=z9hG4bK029.52d62945.0 > Via: SIP/2.0/UDP 134.121.32.130:5060 > ;rport=5060;branch=z9hG4bK091005111656091709252938 > From: sip:919731573290@134.121.32.130;tag=09100511163117092280006157 > Call-ID: b637fa62393a45a0a58633c1a8f43a86 > To: sip:austin@134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46 > Content-Length: 0 > > > SIP/2.0 200 OK > Via: SIP/2.0/UDP > 134.33.8.138;received=134.33.8.138;branch=z9hG4bK029.52d62945.0 > Via: SIP/2.0/UDP 134.121.32.130:5060 > ;rport=5060;branch=z9hG4bK091005111656091709252938 > Call-ID: b637fa62393a45a0a58633c1a8f43a86 > From: <sip:919731573290@134.121.32.130>;tag=09100511163117092280006157 > To: <sip:austin@134.121.32.130>;tag=8c2e350c064e417c96bda1378470fd46 > CSeq: 1 BYE > Content-Length: 0 > > > > > On Sun, Oct 9, 2011 at 11:50 AM, Sammy Govind <govoi...@gmail.com> wrote: > >> Hey, >> Can you send in the SIP/SDP invites. I suspect the codecs issue here. >> -- >> Regards, >> Sammy >> >> >> On Sun, Oct 9, 2011 at 8:57 AM, Austin Einter >> <austin.ein...@gmail.com>wrote: >> >>> Hi >>> I am using Kamailio 3.1.5 . I am using RTP proxy also. >>> I have used default kamailio.cfg.sample fiile , and just added line >>> #!define WITH_NAT. >>> >>> I have another Main proxy. I wanted all my signalling and media packets >>> should just pass through machine where Kamailio and RTP proxy are running. >>> >>> With this I found, call is established, all signalling and media packets >>> are passing through kamailio / rtp-proxy. >>> So far so good. >>> >>> One way audio stream (from called party to calling party) quality is >>> good. >>> The other audio stream (from calling party to called party is very bad. >>> >>> Did anybody face this issue? Please help me to sort out this issue audio >>> quality issue. >>> >>> Regards >>> Austin >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >> >> _______________________________________________ >> 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 >> >> > > _______________________________________________ > 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 > >
_______________________________________________ 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
