Different codec priorities in 1xx and 200
Hi,
I've noticed a one-way audio problem with one of the SIP providers.
It's definitely a media issue, not a network issue. I make a call,
another party answers and hears me, but I can't her another party.
When he or she starts speaking, the output on my side says
"strm0x98fd74 Bad RTP pt 8 (expecting 117)"
I've noticed that there are different codec priorities in 183 and in
200 replies from that provider. When it replies with 183 with iLBC as
the most preferred codec, pjsua-lib sais
pjsua_media.c Media updates, stream #0: iLBC (sendrecv)
Later, when provider replies with 200 and PCMA as the most preferred
codec, there are no "Media updates" in the pjsua-lib log output and
there is "SDP negotiation done, message body is ignored" instead. And
error messages start appearing when another party speaks.
Is such behaviour of that SIP provider appropriate? Should pjsua-lib
adapt to the codec changes between 1xx and 2xx?
Alexei
17:20:38.866 pjsua_core.c TX 1318 bytes Request msg INVITE/
cseq=31721 (tdta0x85fa00) to UDP 217.73.112.14:5060:
INVITE sip:012345678901@sip.pctel.ru SIP/2.0
Via: SIP/2.0/UDP
91.78.58.52:5060;rport;branch=z9hG4bKPjH4fxoJD4c4kpDnZbuWrNO2THj01FD-Jb
Max-Forwards: 70
From: sip:johnsmith@sip.pctel.ru;tag=GX09pOKuM86R75zTInh0NIq.M06tHfG3
To: sip:012345678901@sip.pctel.ru
Contact: sip:johnsmith@91.78.58.52:5060
Call-ID: tXloaqtu3fCEUw9fnE0EHxAJpWHGoh9e
CSeq: 31721 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, norefersub
User-Agent: PJSUA v1.0.2/i386-apple-darwin9.6.0
Authorization: Digest username="johnsmith", realm="sip.pctel.ru",
nonce="49edc952a4cf810a00e6bae7252c2707601bf829", uri="sip:012345678901@sip.pctel.ru
", response="c8a54e3a5f7d1d4a9e15549f46f527e3",
cnonce="hsrQ4p0kagPMvuwq6OMEMpnGuEIMX9re", qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length: 456
v=0
o=- 3449308838 3449308838 IN IP4 91.78.58.52
s=pjmedia
c=IN IP4 91.78.58.52
t=0 0
a=X-nat:8
m=audio 4000 RTP/AVP 103 102 104 117 3 0 8 9 101
a=rtcp:4001 IN IP4 91.78.58.52
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:104 speex/32000
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
--end msg--
17:20:38.866 pjsua_app.c Call 0 state changed to CALLING
17:20:38.906 pjsua_core.c RX 309 bytes Response msg 100/INVITE/
cseq=31721 (rdata0x82b064) from UDP 217.73.112.14:5060:
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP
91.78.58.52
:5060;rport=5060;branch=z9hG4bKPjH4fxoJD4c4kpDnZbuWrNO2THj01FD-Jb
From: sip:johnsmith@sip.pctel.ru;tag=GX09pOKuM86R75zTInh0NIq.M06tHfG3
To: sip:012345678901@sip.pctel.ru
Call-ID: tXloaqtu3fCEUw9fnE0EHxAJpWHGoh9e
CSeq: 31721 INVITE
Content-Length: 0
--end msg--
17:20:39.105 pjsua_core.c RX 793 bytes Response msg 183/INVITE/
cseq=31721 (rdata0x82b064) from UDP 217.73.112.14:5060:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
91.78.58.52
:5060;rport=5060;branch=z9hG4bKPjH4fxoJD4c4kpDnZbuWrNO2THj01FD-Jb
From: sip:johnsmith@sip.pctel.ru;tag=GX09pOKuM86R75zTInh0NIq.M06tHfG3
To: sip:012345678901@sip.pctel.ru;tag=as4dac19c9
Call-ID: tXloaqtu3fCEUw9fnE0EHxAJpWHGoh9e
CSeq: 31721 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: sip:012345678901@217.73.112.9:5060
Content-Type: application/sdp
Content-Length: 291
v=0
o=root 30663 30663 IN IP4 217.73.112.9
s=session
c=IN IP4 217.73.112.9
t=0 0
m=audio 18218 RTP/AVP 117 8 0 3 101
a=rtpmap:117 iLBC/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
--end msg--
17:20:39.105 pjsua_app.c Call 0 state changed to EARLY (183
Session Progress)
17:20:39.128 strm0x865b74 VAD temporarily disabled
17:20:39.129 strm0x865b74 Encoder stream started
17:20:39.129 strm0x865b74 Decoder stream started
17:20:39.129 pjsua_media.c Media updates, stream #0: iLBC (sendrecv)
17:20:39.129 conference.c Port 3 (sip:012345678901@sip.pctel.ru)
transmitting to port 0 (Built-in Microphone)
17:20:39.129 conference.c Port 0 (Built-in Microphone)
transmitting to port 3 (sip:012345678901@sip.pctel.ru)
17:20:39.129 pjsua_app.c Media for call 0 is active
17:20:39.131 Master/sound Underflow, buf_cnt=0, will generate 1
frame
17:20:39.778 strm0x865b74 VAD re-enabled
17:20:49.469 pjsua_core.c RX 820 bytes Response msg 200/INVITE/
cseq=31721 (rdata0x82b064) from UDP 217.73.112.14:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
91.78.58.52
:5060;rport=5060;branch=z9hG4bKPjH4fxoJD4c4kpDnZbuWrNO2THj01FD-Jb
Record-Route: sip:217.73.112.14;lr=on
From: sip:johnsmith@sip.pctel.ru;tag=GX09pOKuM86R75zTInh0NIq.M06tHfG3
To: sip:012345678901@sip.pctel.ru;tag=as4dac19c9
Call-ID: tXloaqtu3fCEUw9fnE0EHxAJpWHGoh9e
CSeq: 31721 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: sip:012345678901@217.73.112.9:5060
Content-Type: application/sdp
Content-Length: 291
v=0
o=root 30663 30664 IN IP4 217.73.112.9
s=session
c=IN IP4 217.73.112.9
t=0 0
m=audio 18218 RTP/AVP 8 117 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:117 iLBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
--end msg--
17:20:49.470 pjsua_app.c Call 0 state changed to CONNECTING
17:20:49.470 inv0x85bc64 SDP negotiation done, message body is
ignored
17:20:49.470 pjsua_core.c TX 388 bytes Request msg ACK/cseq=31721
(tdta0x86c200) to UDP 217.73.112.14:5060:
ACK sip:012345678901@217.73.112.9:5060 SIP/2.0
Via: SIP/2.0/UDP
91.78.58.52:5060;rport;branch=z9hG4bKPjnUzGc4KND2SpWxshSKHX8DMbQ1numik6
Max-Forwards: 70
From: sip:johnsmith@sip.pctel.ru;tag=GX09pOKuM86R75zTInh0NIq.M06tHfG3
To: sip:012345678901@sip.pctel.ru;tag=as4dac19c9
Call-ID: tXloaqtu3fCEUw9fnE0EHxAJpWHGoh9e
CSeq: 31721 ACK
Route: sip:217.73.112.14;lr
Content-Length: 0
--end msg--
17:20:49.470 pjsua_app.c Call 0 state changed to CONFIRMED
17:20:49.616 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.626 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.641 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.668 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.684 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.704 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.724 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.741 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.761 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.784 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.804 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.824 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.842 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.861 strm0x865b74 Bad RTP pt 8 (expecting 117)
Hi Alexei,
Alexei Kuznetsov wrote:
Hi,
I've noticed a one-way audio problem with one of the SIP providers. It's
definitely a media issue, not a network issue. I make a call, another
party answers and hears me, but I can't her another party. When he or
she starts speaking, the output on my side says
can you please name one of those providers?
Thanks
Mike
On Tue, Apr 21, 2009 at 5:43 PM, Michael Bradley Jr
mbradley.jr@gmail.com wrote:
I've noticed a one-way audio problem with one of the SIP providers. It's
definitely a media issue, not a network issue. I make a call, another
party answers and hears me, but I can't her another party. When he or
she starts speaking, the output on my side says
can you please name one of those providers?
In my case it is the Russian provider pctel.ru.
Alexei
This provider's SDP answer isn't correct.
For SDP, it should be only one answer for an offer.
If offer in invite, answer must be first reliable response, which is only
2xx in RFC 3261, extended in other RFCs.
If answer in provisional response, then need repeated in the 200.
regards,
Gang
On Tue, Apr 21, 2009 at 10:46 PM, Alexei Kuznetsov eofster@gmail.comwrote:
On Tue, Apr 21, 2009 at 5:43 PM, Michael Bradley Jr
mbradley.jr@gmail.com wrote:
I've noticed a one-way audio problem with one of the SIP providers. It's
definitely a media issue, not a network issue. I make a call, another
party answers and hears me, but I can't her another party. When he or
she starts speaking, the output on my side says
can you please name one of those providers?
In my case it is the Russian provider pctel.ru.
Alexei
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
pjsua is known to not support asymmetric codecs - it expects to receive
the same codec as it sends.
regards
klaus
Alexei Kuznetsov schrieb:
Hi,
I've noticed a one-way audio problem with one of the SIP providers. It's
definitely a media issue, not a network issue. I make a call, another
party answers and hears me, but I can't her another party. When he or
she starts speaking, the output on my side says
"strm0x98fd74 Bad RTP pt 8 (expecting 117)"
I've noticed that there are different codec priorities in 183 and in 200
replies from that provider. When it replies with 183 with iLBC as the
most preferred codec, pjsua-lib sais
pjsua_media.c Media updates, stream #0: iLBC (sendrecv)
Later, when provider replies with 200 and PCMA as the most preferred
codec, there are no "Media updates" in the pjsua-lib log output and
there is "SDP negotiation done, message body is ignored" instead. And
error messages start appearing when another party speaks.
Is such behaviour of that SIP provider appropriate? Should pjsua-lib
adapt to the codec changes between 1xx and 2xx?
Alexei
17:20:38.866 pjsua_core.c TX 1318 bytes Request msg INVITE/cseq=31721
(tdta0x85fa00) to UDP 217.73.112.14:5060:
INVITE sip:012345678901@sip.pctel.ru SIP/2.0
Via: SIP/2.0/UDP
91.78.58.52:5060;rport;branch=z9hG4bKPjH4fxoJD4c4kpDnZbuWrNO2THj01FD-Jb
Max-Forwards: 70
From: sip:johnsmith@sip.pctel.ru;tag=GX09pOKuM86R75zTInh0NIq.M06tHfG3
To: sip:012345678901@sip.pctel.ru
Contact: sip:johnsmith@91.78.58.52:5060
Call-ID: tXloaqtu3fCEUw9fnE0EHxAJpWHGoh9e
CSeq: 31721 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, norefersub
User-Agent: PJSUA v1.0.2/i386-apple-darwin9.6.0
Authorization: Digest username="johnsmith", realm="sip.pctel.ru",
nonce="49edc952a4cf810a00e6bae7252c2707601bf829",
uri="sip:012345678901@sip.pctel.ru",
response="c8a54e3a5f7d1d4a9e15549f46f527e3",
cnonce="hsrQ4p0kagPMvuwq6OMEMpnGuEIMX9re", qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length: 456
v=0
o=- 3449308838 3449308838 IN IP4 91.78.58.52
s=pjmedia
c=IN IP4 91.78.58.52
t=0 0
a=X-nat:8
m=audio 4000 RTP/AVP 103 102 104 117 3 0 8 9 101
a=rtcp:4001 IN IP4 91.78.58.52
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:104 speex/32000
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
--end msg--
17:20:38.866 pjsua_app.c Call 0 state changed to CALLING
17:20:38.906 pjsua_core.c RX 309 bytes Response msg
100/INVITE/cseq=31721 (rdata0x82b064) from UDP 217.73.112.14:5060:
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP
91.78.58.52:5060;rport=5060;branch=z9hG4bKPjH4fxoJD4c4kpDnZbuWrNO2THj01FD-Jb
From: sip:johnsmith@sip.pctel.ru;tag=GX09pOKuM86R75zTInh0NIq.M06tHfG3
To: sip:012345678901@sip.pctel.ru
Call-ID: tXloaqtu3fCEUw9fnE0EHxAJpWHGoh9e
CSeq: 31721 INVITE
Content-Length: 0
--end msg--
17:20:39.105 pjsua_core.c RX 793 bytes Response msg
183/INVITE/cseq=31721 (rdata0x82b064) from UDP 217.73.112.14:5060:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
91.78.58.52:5060;rport=5060;branch=z9hG4bKPjH4fxoJD4c4kpDnZbuWrNO2THj01FD-Jb
From: sip:johnsmith@sip.pctel.ru;tag=GX09pOKuM86R75zTInh0NIq.M06tHfG3
To: sip:012345678901@sip.pctel.ru;tag=as4dac19c9
Call-ID: tXloaqtu3fCEUw9fnE0EHxAJpWHGoh9e
CSeq: 31721 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: sip:012345678901@217.73.112.9:5060
Content-Type: application/sdp
Content-Length: 291
v=0
o=root 30663 30663 IN IP4 217.73.112.9
s=session
c=IN IP4 217.73.112.9
t=0 0
m=audio 18218 RTP/AVP 117 8 0 3 101
a=rtpmap:117 iLBC/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
--end msg--
17:20:39.105 pjsua_app.c Call 0 state changed to EARLY (183 Session
Progress)
17:20:39.128 strm0x865b74 VAD temporarily disabled
17:20:39.129 strm0x865b74 Encoder stream started
17:20:39.129 strm0x865b74 Decoder stream started
17:20:39.129 pjsua_media.c Media updates, stream #0: iLBC (sendrecv)
17:20:39.129 conference.c Port 3 (sip:012345678901@sip.pctel.ru)
transmitting to port 0 (Built-in Microphone)
17:20:39.129 conference.c Port 0 (Built-in Microphone) transmitting
to port 3 (sip:012345678901@sip.pctel.ru)
17:20:39.129 pjsua_app.c Media for call 0 is active
17:20:39.131 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:20:39.778 strm0x865b74 VAD re-enabled
17:20:49.469 pjsua_core.c RX 820 bytes Response msg
200/INVITE/cseq=31721 (rdata0x82b064) from UDP 217.73.112.14:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
91.78.58.52:5060;rport=5060;branch=z9hG4bKPjH4fxoJD4c4kpDnZbuWrNO2THj01FD-Jb
Record-Route: sip:217.73.112.14;lr=on
From: sip:johnsmith@sip.pctel.ru;tag=GX09pOKuM86R75zTInh0NIq.M06tHfG3
To: sip:012345678901@sip.pctel.ru;tag=as4dac19c9
Call-ID: tXloaqtu3fCEUw9fnE0EHxAJpWHGoh9e
CSeq: 31721 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: sip:012345678901@217.73.112.9:5060
Content-Type: application/sdp
Content-Length: 291
v=0
o=root 30663 30664 IN IP4 217.73.112.9
s=session
c=IN IP4 217.73.112.9
t=0 0
m=audio 18218 RTP/AVP 8 117 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:117 iLBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
--end msg--
17:20:49.470 pjsua_app.c Call 0 state changed to CONNECTING
17:20:49.470 inv0x85bc64 SDP negotiation done, message body is ignored
17:20:49.470 pjsua_core.c TX 388 bytes Request msg ACK/cseq=31721
(tdta0x86c200) to UDP 217.73.112.14:5060:
ACK sip:012345678901@217.73.112.9:5060 SIP/2.0
Via: SIP/2.0/UDP
91.78.58.52:5060;rport;branch=z9hG4bKPjnUzGc4KND2SpWxshSKHX8DMbQ1numik6
Max-Forwards: 70
From: sip:johnsmith@sip.pctel.ru;tag=GX09pOKuM86R75zTInh0NIq.M06tHfG3
To: sip:012345678901@sip.pctel.ru;tag=as4dac19c9
Call-ID: tXloaqtu3fCEUw9fnE0EHxAJpWHGoh9e
CSeq: 31721 ACK
Route: sip:217.73.112.14;lr
Content-Length: 0
--end msg--
17:20:49.470 pjsua_app.c Call 0 state changed to CONFIRMED
17:20:49.616 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.626 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.641 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.668 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.684 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.704 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.724 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.741 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.761 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.784 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.804 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.824 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.842 strm0x865b74 Bad RTP pt 8 (expecting 117)
17:20:49.861 strm0x865b74 Bad RTP pt 8 (expecting 117)
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Hi gang!
Gang Liu schrieb:
This provider's SDP answer isn't correct.
For SDP, it should be only one answer for an offer.
If offer in invite, answer must be first reliable response, which is
only 2xx in RFC 3261, extended in other RFCs.
If answer in provisional response, then need repeated in the 200.
I wonder if it would be standard conform if the 200 OK uses a different
to-tag (as then it would be a different dialog).
regards
klaus
regards,
Gang
On Tue, Apr 21, 2009 at 10:46 PM, Alexei Kuznetsov <eofster@gmail.com
mailto:eofster@gmail.com> wrote:
On Tue, Apr 21, 2009 at 5:43 PM, Michael Bradley Jr
<mbradley.jr@gmail.com <mailto:mbradley.jr@gmail.com>> wrote:
I've noticed a one-way audio problem with one of the SIP
providers. It's
definitely a media issue, not a network issue. I make a call,
another
party answers and hears me, but I can't her another party. When
he or
she starts speaking, the output on my side says
can you please name one of those providers?
In my case it is the Russian provider pctel.ru <http://pctel.ru/>.
Alexei
_______________________________________________
Visit our blog: http://blog.pjsip.org <http://blog.pjsip.org/>
pjsip mailing list
pjsip@lists.pjsip.org <mailto:pjsip@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
What you said is only will happen when call forked.
But from SIP message above, call not forked.
This isn't asymmetric codecs case.
The UAS created two different SDP answer for one offer. orig line is
different.
regards,
Gang
On 4/23/09, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi gang!
Gang Liu schrieb:
This provider's SDP answer isn't correct.
For SDP, it should be only one answer for an offer.
If offer in invite, answer must be first reliable response, which is only
2xx in RFC 3261, extended in other RFCs.
If answer in provisional response, then need repeated in the 200.
I wonder if it would be standard conform if the 200 OK uses a different
to-tag (as then it would be a different dialog).
regards
klaus
regards,
Gang
On Tue, Apr 21, 2009 at 10:46 PM, Alexei Kuznetsov <eofster@gmail.com<mailto:
eofster@gmail.com>> wrote:
On Tue, Apr 21, 2009 at 5:43 PM, Michael Bradley Jr
<mbradley.jr@gmail.com <mailto:mbradley.jr@gmail.com>> wrote:
I've noticed a one-way audio problem with one of the SIP
providers. It's
definitely a media issue, not a network issue. I make a call,
another
party answers and hears me, but I can't her another party. When
he or
she starts speaking, the output on my side says
can you please name one of those providers?
In my case it is the Russian provider pctel.ru <http://pctel.ru/>.
Alexei
_______________________________________________
Visit our blog: http://blog.pjsip.org <http://blog.pjsip.org/>
pjsip mailing list
pjsip@lists.pjsip.org <mailto:pjsip@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Gang Liu schrieb:
What you said is only will happen when call forked.
But from SIP message above, call not forked.
This isn't asymmetric codecs case.
The UAS created two different SDP answer for one offer. orig line is
different.
Yes, that is true. But as a dirty workaround, if the GW wants to change
SDP between 183 and 200 it could use a new totag in the 200 ok.
regards
klaus
regards,
Gang
On 4/23/09, Klaus Darilion <klaus.mailinglists@pernau.at
mailto:klaus.mailinglists@pernau.at> wrote:
Hi gang!
Gang Liu schrieb:
This provider's SDP answer isn't correct.
For SDP, it should be only one answer for an offer.
If offer in invite, answer must be first reliable response,
which is only 2xx in RFC 3261, extended in other RFCs.
If answer in provisional response, then need repeated in the 200.
I wonder if it would be standard conform if the 200 OK uses a
different to-tag (as then it would be a different dialog).
regards
klaus
regards,
Gang
On Tue, Apr 21, 2009 at 10:46 PM, Alexei Kuznetsov
<eofster@gmail.com <mailto:eofster@gmail.com>
<mailto:eofster@gmail.com <mailto:eofster@gmail.com>>> wrote:
On Tue, Apr 21, 2009 at 5:43 PM, Michael Bradley Jr
<mbradley.jr@gmail.com <mailto:mbradley.jr@gmail.com>
<mailto:mbradley.jr@gmail.com <mailto:mbradley.jr@gmail.com>>>
wrote:
I've noticed a one-way audio problem with one of the SIP
providers. It's
definitely a media issue, not a network issue. I make a call,
another
party answers and hears me, but I can't her another
party. When
he or
she starts speaking, the output on my side says
can you please name one of those providers?
In my case it is the Russian provider pctel.ru
<http://pctel.ru> <http://pctel.ru/>.
Alexei
_______________________________________________
Visit our blog: http://blog.pjsip.org <http://blog.pjsip.org/>
pjsip mailing list
pjsip@lists.pjsip.org <mailto:pjsip@lists.pjsip.org>
<mailto:pjsip@lists.pjsip.org <mailto:pjsip@lists.pjsip.org>>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
------------------------------------------------------------------------
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org <mailto:pjsip@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org <mailto:pjsip@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
It is better to use UPDATE or re-INVITE.
regards,
Gang
On Thu, Apr 23, 2009 at 9:32 PM, Klaus Darilion <
klaus.mailinglists@pernau.at> wrote:
Gang Liu schrieb:
What you said is only will happen when call forked.
But from SIP message above, call not forked.
This isn't asymmetric codecs case.
The UAS created two different SDP answer for one offer. orig line is
different.
Yes, that is true. But as a dirty workaround, if the GW wants to change SDP
between 183 and 200 it could use a new totag in the 200 ok.
regards
klaus
regards,
Gang
On 4/23/09, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:
klaus.mailinglists@pernau.at>> wrote:
Hi gang!
Gang Liu schrieb:
This provider's SDP answer isn't correct.
For SDP, it should be only one answer for an offer.
If offer in invite, answer must be first reliable response,
which is only 2xx in RFC 3261, extended in other RFCs.
If answer in provisional response, then need repeated in the 200.
I wonder if it would be standard conform if the 200 OK uses a
different to-tag (as then it would be a different dialog).
regards
klaus
regards,
Gang
On Tue, Apr 21, 2009 at 10:46 PM, Alexei Kuznetsov
<eofster@gmail.com <mailto:eofster@gmail.com>
<mailto:eofster@gmail.com <mailto:eofster@gmail.com>>> wrote:
On Tue, Apr 21, 2009 at 5:43 PM, Michael Bradley Jr
<mbradley.jr@gmail.com <mailto:mbradley.jr@gmail.com>
<mailto:mbradley.jr@gmail.com <mailto:mbradley.jr@gmail.com>>>
wrote:
I've noticed a one-way audio problem with one of the SIP
providers. It's
definitely a media issue, not a network issue. I make a
call,
another
party answers and hears me, but I can't her another
party. When
he or
she starts speaking, the output on my side says
can you please name one of those providers?
In my case it is the Russian provider pctel.ru
<http://pctel.ru> <http://pctel.ru/>.
Alexei
_______________________________________________
Visit our blog: http://blog.pjsip.org <http://blog.pjsip.org/>
pjsip mailing list
pjsip@lists.pjsip.org <mailto:pjsip@lists.pjsip.org>
<mailto:pjsip@lists.pjsip.org <mailto:pjsip@lists.pjsip.org>>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org <mailto:pjsip@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org <mailto:pjsip@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org