Jump to content

One way audio


rune
 Share

Recommended Posts

Hi,

 

I have a problem with one way audio when I recieve incomming call on the trunk.

 

My setup:

The pbxnsip is placed on a LAN behind a DLINK 603 router. On the same network I have 3 sip-phones.

The pbxnsip has a registration on musimi.dk. The trunk is configured to forward incomming call to extention "2222".

The 3 sip phones has each a registration on the pbxnsip (phone number 1111,2222,3333).

 

If I make an incomming call to the musimi account (the trunk on pbxnsip), phone 2222 alerts, when I answer there is no TX audio from phone 2222 to the external device. Any hints why? Does the pbxnsip requires a public IP address to route the RTP correctly? What NAT traversal features does pbxnsip have? I cannot find a setting for rport or ice.

 

I have made an wireshark trace and audio from the extention unit is routed correctly to the pbxnsip (I have checked ports, ip-addresses).

 

If I move the trunk SIP account to another phone on the LAN and make an incomming call there is audio both ways (I have enabled rport on the device). Likewise if phone 1111 calls 2222 (internal call on the pbx) audio is also working fine.

 

Another issue is that if the trunk registration has multiple bindings on the external SIP server (in this case musimi) the pbx cancelles the incomming call when the all is answered.

Link to comment
Share on other sites

I have another question :)

 

How come the SSRC changes, when I answers a call? (please note that all codec's and sdp session Id is the same)

 

I cannot find anywhere where this isent allowed, but what is the point in creating a new RTP instance?

 

The only thing I can find in rfc-3550 is:

"Because the randomly allocated SSRC identifier may change if a

conflict is discovered or if a program is restarted"

 

I am 100% sure that the SSRC's are different and that the phones hasent restarted.

Link to comment
Share on other sites

Well, it is allowed. The IETF's opinion about music on hold is that the music comes from another server, and that server uses a different SSRC, timestamp and packet number.

 

But it seems to be a challenge for compability of some devices. Maybe we have to make it possible that these parameters do not change and avoid the problems.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...