Hi,
We are using openser with media proxy and radiator. We're having audio problems when we send calls to mediatrix gateway for termination. Internal calls work fine. We hear audio both side and we can see the session and bytes transfer properly in media proxy monitoring webpage. When we send calls to mediatrix gateway for termination, calls connect properly but we don't hear audio. We see inactive session in mediaproxy status page with no bytes transferring. One doubt I have is it is not entering reply route when it receives replies like 183, 180, etc. Has anyone encountered similar issue? How can we fix it? Thanks in advance!
El Wednesday 14 May 2008 14:10:46 Krunal Patel escribió:
Hi,
We are using openser with media proxy and radiator. We're having audio problems when we send calls to mediatrix gateway for termination. Internal calls work fine. We hear audio both side and we can see the session and bytes transfer properly in media proxy monitoring webpage. When we send calls to mediatrix gateway for termination, calls connect properly but we don't hear audio. We see inactive session in mediaproxy status page with no bytes transferring. One doubt I have is it is not entering reply route when it receives replies like 183, 180, etc. Has anyone encountered similar issue? How can we fix it? Thanks in advance!
Examine the negoziated SDP (the IP and ports) of each side (caller and called) and determine if it makes sense or someone is sending audio to a wrong place.
Hi,
Actually I am new to openser. Here i am sending trace from openser. So please check out SDP. Thanking in advance.
Message Body: INVITE sip:999999999@voip.domain.comsip%3A999999999@voip.domain.comSIP/2.0 Via: SIP/2.0/UDP 122.xxx.xxx.35:5061;rport;branch=z9hG4bK7F77064E8D8FD3FD41779B0F67EF5C05 From: 5555555555 sip:5555555555@voip.domain.com:5061;tag=2027736222 To: <sip:999999999@voip.domain.com sip%3A999999999@voip.domain.com> Contact: sip:5555555555@122.xxx.xxx.35:5061 Call-ID: 64E8EEAF-6014-1CCB-98A5-1185295C388B@192.168.1.10 CSeq: 28079 INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1105d Content-Length: 291
v=0 o=5555555555 3961416264 3961416447 IN IP4 122.xxx.xxx.35 s=X-Lite c=IN IP4 122.xxx.xxx.35 t=0 0 m=audio 8000 RTP/AVP 0 8 3 98 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv
Message Body: INVITE sip:999999999@voip.domain.comsip%3A999999999@voip.domain.comSIP/2.0 Via: SIP/2.0/UDP 122.xxx.xxx.35:5061;rport;branch=z9hG4bK200ED8B65B4AFC558C060A0A8B5FE1ED From: 5555555555 sip:5555555555@voip.domain.com:5061;tag=2027736222 To: <sip:999999999@voip.domain.com sip%3A999999999@voip.domain.com> Contact: sip:5555555555@122.xxx.xxx.35:5061 Call-ID: 64E8EEAF-6014-1CCB-98A5-1185295C388B@192.168.1.10 CSeq: 28080 INVITE Proxy-Authorization: Digest username="5555555555",realm="voip.domain.com ",nonce="482c8213b23f69ac2b268e593620cb2367dc643b",response="7a7d3cf46a5b7cf90cc623664ca52e4d",uri=" sip:999999999@voip.domain.com sip%3A999999999@voip.domain.com" Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1105d Content-Length: 291
v=0 o=5555555555 3961416264 3961416447 IN IP4 122.xxx.xxx.35 s=X-Lite c=IN IP4 122.xxx.xxx.35 t=0 0 m=audio 8000 RTP/AVP 0 8 3 98 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv
SIP/2.0 183 Session Progress Call-ID: 64E8EEAF-6014-1CCB-98A5-1185295C388B@192.168.1.10 CSeq: 28080 INVITE From: 5555555555 sip:5555555555@voip.domain.com:5061;tag=2027736222 To: <sip:999999999@voip.domain.com sip%3A999999999@voip.domain.com
;tag=5430ebc2c5d6575
Via: SIP/2.0/UDP 122.xxx.xxx.35:5061;branch=z9hG4bK200ED8B65B4AFC558C060A0A8B5FE1ED;rport=5061 Record-Route: sip:voip.domain.com:5060;nat=yes;ftag=2027736222;lr=on Content-Length: 209 Content-Type: application/sdp Contact: sip:999999999@213.XXX.XXX.28:5060 User-Agent: Mediatrix MDD1404 2404 1500 1600 2500 2600 MxSF v3.2.8.45 00a0ba009b05
v=0 o=MxSIP 0 7983 IN IP4 213.XXX.XXX.28 s=SIP Call c=IN IP4 213.XXX.XXX.28 t=0 0 m=audio 19462 RTP/AVP 0 8 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv
SIP/2.0 200 OK Call-ID: 64E8EEAF-6014-1CCB-98A5-1185295C388B@192.168.1.10 CSeq: 28080 INVITE From: 5555555555 sip:5555555555@voip.domain.com:5061;tag=2027736222 To: <sip:999999999@voip.domain.com sip%3A999999999@voip.domain.com
;tag=5430ebc2c5d6575
Via: SIP/2.0/UDP 122.xxx.xxx.35:5061;branch=z9hG4bK200ED8B65B4AFC558C060A0A8B5FE1ED;rport=5061 Record-Route: sip:voip.domain.com:5060;nat=yes;ftag=2027736222;lr=on Content-Length: 209 Content-Type: application/sdp Supported: replaces Contact: sip:999999999@213.XXX.XXX.28:5060 User-Agent: Mediatrix MDD1404 2404 1500 1600 2500 2600 MxSF v3.2.8.45 00a0ba009b05
v=0 o=MxSIP 0 7983 IN IP4 213.XXX.XXX.28 s=SIP Call c=IN IP4 213.XXX.XXX.28 t=0 0 m=audio 19462 RTP/AVP 0 8 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv
SIP/2.0 200 OK Call-ID: 64E8EEAF-6014-1CCB-98A5-1185295C388B@192.168.1.10 CSeq: 28080 INVITE From: 5555555555 sip:5555555555@voip.domain.com:5061;tag=2027736222 To: <sip:999999999@voip.domain.com sip%3A999999999@voip.domain.com
;tag=5430ebc2c5d6575
Via: SIP/2.0/UDP 122.xxx.xxx.35:5061;branch=z9hG4bK200ED8B65B4AFC558C060A0A8B5FE1ED;rport=5061 Record-Route: sip:voip.domain.com:5060;nat=yes;ftag=2027736222;lr=on Content-Length: 209 Content-Type: application/sdp Supported: replaces Contact: sip:999999999@213.XXX.XXX.28:5060 User-Agent: Mediatrix MDD1404 2404 1500 1600 2500 2600 MxSF v3.2.8.45 00a0ba009b05
v=0 o=MxSIP 0 7983 IN IP4 213.XXX.XXX.28 s=SIP Call c=IN IP4 213.XXX.XXX.28 t=0 0 m=audio 19462 RTP/AVP 0 8 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv
Message Body: ACK sip:999999999@213.XXX.XXX.28:5060 SIP/2.0 Via: SIP/2.0/UDP 122.xxx.xxx.35:5061;rport;branch=z9hG4bK384293560A7C9508E28212EC0D72CDFA From: 5555555555 sip:5555555555@voip.domain.com:5061;tag=2027736222 To: <sip:999999999@voip.domain.com sip%3A999999999@voip.domain.com
;tag=5430ebc2c5d6575
Contact: sip:5555555555@122.xxx.xxx.35:5061 Route: sip:voip.domain.com:5060;nat=yes;ftag=2027736222;lr=on Call-ID: 64E8EEAF-6014-1CCB-98A5-1185295C388B@192.168.1.10 CSeq: 28080 ACK Max-Forwards: 70 Content-Length: 0
ACK sip:999999999@213.XXX.XXX.28:5060 SIP/2.0 Record-Route: sip:voip.domain.com:5060;nat=yes;ftag=2027736222;lr=on Via: SIP/2.0/UDP 195.XXX.XXX.51;branch=z9hG4bKfacb.bd19b862.2 Via: SIP/2.0/UDP 122.xxx.xxx.35:5061;rport=5061;branch=z9hG4bK384293560A7C9508E28212EC0D72CDFA From: 5555555555 sip:5555555555@voip.domain.com:5061;tag=2027736222 To: <sip:999999999@voip.domain.com sip%3A999999999@voip.domain.com
;tag=5430ebc2c5d6575
Contact: sip:5555555555@122.xxx.xxx.35:5061 Call-ID: 64E8EEAF-6014-1CCB-98A5-1185295C388B@192.168.1.10 CSeq: 28080 ACK Max-Forwards: 69 Content-Length: 0
Message Body: ACK sip:999999999@213.XXX.XXX.28:5060 SIP/2.0 Via: SIP/2.0/UDP 122.xxx.xxx.35:5061;rport;branch=z9hG4bK384293560A7C9508E28212EC0D72CDFA From: 5555555555 sip:5555555555@voip.domain.com:5061;tag=2027736222 To: <sip:999999999@voip.domain.com sip%3A999999999@voip.domain.com
;tag=5430ebc2c5d6575
Contact: sip:5555555555@122.xxx.xxx.35:5061 Route: sip:voip.domain.com:5060;nat=yes;ftag=2027736222;lr=on Call-ID: 64E8EEAF-6014-1CCB-98A5-1185295C388B@192.168.1.10 CSeq: 28080 ACK Max-Forwards: 70 Content-Length: 0
ACK sip:999999999@213.XXX.XXX.28:5060 SIP/2.0 Record-Route: sip:voip.domain.com:5060;nat=yes;ftag=2027736222;lr=on Via: SIP/2.0/UDP 195.XXX.XXX.51;branch=z9hG4bKfacb.bd19b862.2 Via: SIP/2.0/UDP 122.xxx.xxx.35:5061;rport=5061;branch=z9hG4bK384293560A7C9508E28212EC0D72CDFA From: 5555555555 sip:5555555555@voip.domain.com:5061;tag=2027736222 To: <sip:999999999@voip.domain.com sip%3A999999999@voip.domain.com
;tag=5430ebc2c5d6575
Contact: sip:5555555555@122.xxx.xxx.35:5061 Call-ID: 64E8EEAF-6014-1CCB-98A5-1185295C388B@192.168.1.10 CSeq: 28080 ACK Max-Forwards: 69 Content-Length: 0
- Krunal Patel
On Wed, May 14, 2008 at 5:57 PM, Iñaki Baz Castillo ibc@in.ilimit.es wrote:
El Wednesday 14 May 2008 14:10:46 Krunal Patel escribió:
Hi,
We are using openser with media proxy and radiator. We're having audio problems when we send calls to mediatrix gateway for termination. Internal calls work fine. We hear audio both side and we can see the session and bytes transfer properly in media proxy monitoring webpage. When we send calls to mediatrix gateway for termination, calls connect properly but we don't hear audio. We see inactive session in mediaproxy status page with no bytes transferring. One doubt I have is it is not entering reply route when it receives
replies
like 183, 180, etc. Has anyone encountered similar issue? How can we fix it? Thanks in advance!
Examine the negoziated SDP (the IP and ports) of each side (caller and called) and determine if it makes sense or someone is sending audio to a wrong place.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
On May 14, 2008, at 2:10 PM, Krunal Patel wrote:
We are using openser with media proxy and radiator. We're having audio problems when we send calls to mediatrix gateway for termination. Internal calls work fine. We hear audio both side and we can see the session and bytes transfer properly in media proxy monitoring webpage. When we send calls to mediatrix gateway for termination, calls connect properly but we don't hear audio. We see inactive session in mediaproxy status page with no bytes transferring. One doubt I have is it is not entering reply route when it receives replies like 183, 180, etc. Has anyone encountered similar issue? How can we fix it?
Actually it's pretty simple, you need to handle the 18x messages just like a 200 OK message!
Thanks a lot Andreas Now it is fixed
On Tue, May 20, 2008 at 3:14 AM, Andreas Sikkema h323@ramdyne.nl wrote:
On May 14, 2008, at 2:10 PM, Krunal Patel wrote:
We are using openser with media proxy and radiator. We're having audio problems when we send calls to mediatrix gateway for termination. Internal calls work fine. We hear audio both side and we can see the session and bytes transfer properly in media proxy monitoring webpage. When we send calls to mediatrix gateway for termination, calls connect properly but we don't hear audio. We see inactive session in mediaproxy status page with no bytes transferring. One doubt I have is it is not entering reply route when it receives replies like 183, 180, etc. Has anyone encountered similar issue? How can we fix it?
Actually it's pretty simple, you need to handle the 18x messages just like a 200 OK message!
-- Andreas Sikkema
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Andreas Sikkema -
Iñaki Baz Castillo -
Krunal Patel