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
