[SR-Users] Audio quality issue
Sammy Govind
govoiper at gmail.com
Mon Oct 10 09:58:17 CEST 2011
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.einter at 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 at 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 at 134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46
> To: sip:919731573290 at 134.121.32.130
> Contact: <sip:austin at 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 at 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 at 134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46
> To: sip:919731573290 at 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 at 134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46
> Call-ID: b637fa62393a45a0a58633c1a8f43a86
> To: sip:919731573290 at 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 at 134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46
> Call-ID: b637fa62393a45a0a58633c1a8f43a86
> To: sip:919731573290 at 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 at 134.121.32.130;tag=8c2e350c064e417c96bda1378470fd46
> To: sip:919731573290 at 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 at 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 at 134.121.32.130;tag=09100511163117092280006157
> Call-ID: b637fa62393a45a0a58633c1a8f43a86
> To: sip:austin at 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 at 134.121.32.130>;tag=09100511163117092280006157
> To: <sip:austin at 134.121.32.130>;tag=8c2e350c064e417c96bda1378470fd46
> CSeq: 1 BYE
> Content-Length: 0
>
>
>
>
> On Sun, Oct 9, 2011 at 11:50 AM, Sammy Govind <govoiper at 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.einter at 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 at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20111010/28e4451e/attachment.htm>
More information about the sr-users
mailing list