I have a running asterisk instalation with a couple of extensions. Yesterday we’ve discovered a strange problem. I’m making an outgoing call (though a sip trunk of our telephony provider). The remote party answers and tries to transfer the call to another extension. Then something strange happens: our asterisk starts playing our own “music on hold” to my extension (I suppose it shoud have forwarded me whatever the remote party was sending in its RTP stream). From then on the call is unrecoverable.
This is the diagram of a traffic flow between the asterisk and our telephony provider. The “music on hold” starts when our asterisk receives the INVITE from the provider. http://postimage.org/image/lmgpoe5z9/
Please, help me understand what is going on. How could the remote party make asterisk play his own music on hold? Is that my misconfiguration?
P.S. My guess would be that the remote party might be sending a DTMF code that makes asterisk behave that way. However dtmf is configured as “inband” in asterisk. Is there a way to detect such dtmf codes with wireshark (or in some other way)?
They’ve made an inbound re-invite at 69.854 which has presumably put the call on hold. That isn’t too unreasonable during a transfer.
I don’t really understand what you mean by a remote transfer, but to me it looks like the provider is handling the transfer (in which case it will probably be in a PSTN numbering context). If the remote party is also VoIP, they may be trying to do a SIP transfer, which would normally result in a hold.
Thanks for your reply. By “remote transfer” I mean that the person who has received the call is trying to pass this call to someone else.
The real problem is that they never get to pass me. I’m listening to my “music on hold” forever no matter what they do on their side. Also I guess that while they are trying to transfer me to someone, they shold be sending me their own music on hold, not expect that I’ll have that configured. But that’s actually a minor issue. The real problem is that the call fails after they do the transfer.
If you are hoping to use features.conf transfers, my guess is that your ITSP also has something like that configured and is intercepting the DTMF.
On modern SIP systems, hold is signalled by sending a media direction attribute of a=sendonly. Although that technically indicates the party who sent it can still send media, in practice when phones do it, they don’t send media. Because of this (or maybe in spite of it!), Asterisk treats sources that send a=sendonly and media the same as phones, which send a=sendonly without media, and always goes into a local hold state and sends local hold music.
I think the fact that the remote PABX/Gateway is intercepting the transfer request is your real problem, here.