Re: Bad RTP pt 104 (expecting 9) + random source warning

[Kevin Rombach via pjsip <pjsip@xxxxxxxxxxxxxxx>]

Thanks i solved it by disabling all other codes then “G722” in my PJLib. But i think this is not the best solution? :-/ 

I also tried to just disable only the iLBC codec which is requested from the fritz.box. But when i do this im getting 

Bad RTP pt 0 (expecting 9)

instead of 

Bad RTP pt 104 (expecting 9)

Any idea? 

Am 03.08.2017 um 06:35 schrieb Andreas Wehrmann <a.wehrmann@xxxxxxxxxx>:

On 08/02/2017 05:34 PM, Kevin Rombach via pjsip wrote:

08:04:00.871 pjsua_call.c .Call 0 sending UPDATE for updating media session to use only one codec
08:04:00.872 pjsua_core.c ....TX 836 bytes Request msg UPDATE/cseq=5322 (tdta0x75510b58) to UDP 192.168.178.1:5060:
UPDATE sip:EEE303552C7E89C15FFEDA99CA2A7@192.168.178.1 <sip:EEE303552C7E89C15FFEDA99CA2A7@192.168.178.1> SIP/2.0
Via: SIP/2.0/UDP 192.168.178.42:5060;rport;branch=z9hG4bKPjOGaH3-srAqv5CzFr.zdLzHaKV90z789N
Max-Forwards: 70
From: sip:control@xxxxxxxxx;tag=ZOKYABGChnZHwr7GpEuIJbxhc7GeLr6-<sip:control@xxxxxxxxx;tag=ZOKYABGChnZHwr7GpEuIJbxhc7GeLr6->
To: sip:**1@xxxxxxxxx;tag=F723EFB025BCF533 <sip:**1@xxxxxxxxx;tag=F723EFB025BCF533>
Contact: <sip:control@192.168.178.42:5060;ob <sip:control@192.168.178.42:5060;ob>>
Call-ID: ImFJX4NogfS.aPyhSunNEulY6K8fdePa
CSeq: 5322 UPDATE
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800;refresher=uac
Min-SE: 90
Content-Type: application/sdp
Content-Length: 277

v=0
o=- 3710469838 3710469839 IN IP4 192.168.178.42
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 9 96
c=IN IP4 192.168.178.42
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.178.42
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=sendrecv

--end msg--
08:04:00.890 pjsua_core.c .RX 356 bytes Response msg 488/UPDATE/cseq=5322 (rdata0x7550169c) from UDP 192.168.178.1:5060:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP 192.168.178.42:5060;rport=5060;branch=z9hG4bKPjOGaH3-srAqv5CzFr.zdLzHaKV90z789N
From: <sip:control@xxxxxxxxx <sip:control@xxxxxxxxx>>;tag=ZOKYABGChnZHwr7GpEuIJbxhc7GeLr6-
To: <sip:**1@xxxxxxxxx <sip:**1@xxxxxxxxx>>;tag=F723EFB025BCF533
Call-ID: ImFJX4NogfS.aPyhSunNEulY6K8fdePa
CSeq: 5322 UPDATE
User-Agent: FRITZ!OS
Content-Length: 0


--end msg—

08:04:00.951 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:00.983 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.010 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.039 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.072 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.103 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.127 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.159 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.192 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.223 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.247 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.280 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.311 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.343 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.367 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.399 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.431 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.464 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.487 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.519 strm0x75507a64 Bad RTP pt 104 (expecting 9)
08:04:01.551 strm0x75507a64 Bad RTP pt 104 (expecting 9)

The answer is here:

08:04:00.871 pjsua_call.c .Call 0 sending UPDATE for updating media session to use only one codec


PJ is trying to change the session to use only one codec after it has been established.
However, the Fritzbox rejects the UPDATE (which _should_ be fine) and the session continues as is.

IIRC PJ cannot deal with multiple codecs inside a single session,
which is why it tries to change the session to use only one codec.

It would be interesting to know why the Fritzbox rejects the UPDATE, maybe there are some logs on the Fritzbox?

A (cheap) solution would be to limit the codecs that either side supports/offers; (i.e. only allow 'g722' in the fritzbox or PJ).


Regards,
Andreas



_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org