Receive remote on hold information

Hello,

I am new to SIP and you might find my question useless.
Here is my situation:

  • I have a Caller, let’s call him A, it is a PJSIP Client that I developped,
  • I have a Callee, let’s call him B, it is another PJSIP Client that I also developped,
  • I have an Asterisk between them.
  • I have two Wireshark, one on A’s device and the second on B’s device.
    A calls B and B answers. Everything is fine at the moment. My problem is that when I am setting the call on hold on A’s device. I am unable to detect that the call has been set on hold on B’s device.
    With WireShark on A’s device I can see that the set on hold request is transmitted to my Asterisk. However on the other side B never receives a message from Asterisk to be informed that the call has been set on hold.

Is it a configuration problem in Asterisk? Or is it a configuration problem with my SIP clients that I am developping?

Any help would be appreciated :slight_smile:

It’s expected behaviour. Asterisk will interpret an incoming c = 0.0.0.0 or a=sendonly/recvonly/inactive as hold and substitute music on hold, but doesn’t normally send those indications, except to the extent that the SDP response cannot be more permissive than what was received.

It is possible that options have been added to make it pass through hold indications, but I’d have to trawl the pjsip.conf settings to look for those.

Have you looked at:

Well I did not though it was an expected behaviour :slight_smile:
So according to what you mentionned in your second reply :

What will happen if I set the value to “no”? There will be no music played when the call is set on hold? And only that? Or a “message” will be sent to B to inform him that A set on hold the call?
The fact disturbing me is that in PJSIP library you can use an enum called “PJSUA_CALL_MEDIA_REMOTE_HOLD”. Is it only working when you are doing SIP to SIP directly, I wonder?

I think you have yes and no mixed up. The nature of the “message” seems very clear from the comment, although I’d accept there is uncertainty as to whether it also sources MoH.

Asterisk doesn’t use pjsua. The option doesn’t work only for SIP to SIP. The default is “no”.

PJSIP/alice calls PJSIP/bob
PJSIP/bob puts PJSIP/alice on hold

When set to “no” Asterisk plays music on hold to PJSIP/alice.
When set to “yes” Asterisk sends a SIP re-INVITE with sendonly to PJSIP/alice.

Thank you for your help @jcolp. According to what you said and from what I understood there is no explicit “message” telling PJSIP/alice that the call between her and PJSIP/bob has been set on hold by PJSIP/bob? How can I make the difference between a INVITE and re-INVITE? With WireShark sniffing the network I can’t tell, all INVITE messages seem to be the same. So I wonder how I can tell the difference with my SIP client? I guess I will have to detect on PJSIP/alice if a call is already in progress, if I receive a new INVITE it means that the call has been set on hold by PJSIP/bob.

A re-INVITE is sent in-dialog on the call. If the options is set to “yes” then the SIP re-INVITE is sent to PJSIP/alice as I stated, and it is her responsibility to deal with it. She will not receive music on hold from Asterisk in that case. There is no other SIP mechanism used to show she is on hold. AMI does provide Asterisk specific events.

I have no knowledge of your SIP client or environment or any of that. A SIP re-INVITE is a common part of SIP.

An INVITE will only have From tags. A Re-INVITE will have both From and To tags.

It is not the difference between INVITE and Re-INVITE that matters. It is perfectly possible for the initial INVITE to put a media stream on hold from the start of the call. (Also, it isn’t calls that are put on hold, but individual media streams within the call.)