AsteriskNow and Sip 183 with Sendonly

Hi all,
I’m facing a strange behaviour with my AsteriskNow 2.10.0rc1(1.8.11) and Genband/Nortel C20 Softswitch.
When I place a call to a Nortel SS and the called number is busy it sends back a SIP 183 message with sendonly to play the busy tone ( in band ).
In this call scenario, AsteriskNow seems to interpret the sendonly present in 183 as HOLD, and so it play the embedded MOH to the asterisk calling user.
Is there a way to configure AsteriskNow no to interpret sendonly like hold ?

This is the relevant part of the sip debug captured with AsteriskNow

<— SIP read from UDP: —>
SIP/2.0 183 Session Description
Via: SIP/2.0/UDP;received=;branch=z9hG4bK14184f3c;rport=32699
From: “50289081219”;tag=as46810d90
CSeq: 103 INVITE
Content-Type: application/sdp
Contact: sip:0289089584@;maddr=;transport=udp
User-Agent: Nortel SESM
Supported: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec,join,x-nortel-sipvc,
Content-Length: 233

o=NNMAS 1 864 IN IP4
c=IN IP4
t=0 0
m=audio 34150 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
— (11 headers 12 lines) —
list_route: hop: sip:0289089584@;maddr=;transport=udp
Found RTP audio format 8
Found RTP audio format 101
Found audio description format PCMA for ID 8
Found audio description format telephone-event for ID 101
Capabilities: us - 0x108 (alaw|g729), peer - audio=0x8 (alaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port
– Call on SIP/50289081219-00000011 placed on hold
– Started music on hold, class ‘default’, on SIP/250-00000010
– SIP/50289081219-00000011 is making progress passing it to SIP/250-00000010
Audio is at 10328
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<— Transmitting (no NAT) to —>
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP;branch=z9hG4bK43e92e02f5837e001;received=
From: “250” sip:250@;tag=60391607da
To: sip:0289089584@;tag=as15835675
Call-ID: 918e2f896a980d2d
CSeq: 1580684441 INVITE
Server: AFPBX-2.10.0rc1(1.8.11)-
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: sip:0289089584@
Content-Type: application/sdp
Content-Length: 229

o=root 1526534939 1526534939 IN IP4
c=IN IP4
t=0 0
m=audio 10328 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Thanks to all for all the help you can give me :smile:

Sending media direction sendonly is the de facto modern way of signalling hold. Unfortunately phones do this without sending media, so one tends to have to assume it requires local generation of MoH, even if the upstream is providing MoH, or, in this case, early media. I don’t believe there is any way to get Asterisk to give priority to the upstream media stream when sendonly is set.

(I have seen suggestions that hold is actually a combination of media address and sendonly, but I’m not aware of an RFC that says this, and Asterisk treats either as indicating hold. Using just is deprecated.)

Incidentally, fortunately this is to do with Asterisk, not AsteriskNow; otherwise you would have been off topic.

How about taking asterisk out of the media path with directmedia/directmediapermit directives ?

This actually gets messy for normal media. However, in this case, they are talking about early media, and directmedia only comes into affect on the transition from the early to the normal phase of the call.

For normal media, Asterisk will try and source music on hold, in parallel with the direct media, with the result that the recipient can get somewhat confused, and one, the other, or a garbled mix. I don’t believe this is fixed in later versions - it relates to the fact that Asterisk treats sendonly as hold from upstream, but doesn’t attach sendonly to downstream holds.

Note, we have found some PABXes that don’t like it when a modified Asterisk sends sendonly with downstream music on hold, a feature we implemented to support some other local extensions.

It might be worth trying directrtpsetup then.

directrtpsetup has experimental status, and I would have no confidence that it would handle sendonly sensibly.

We have had a response from the genband side saying that the send only should not be treated as a call hold.
They say that as the media channel has not been established it cannot be placed on hold. The 183 establishes the media channel as a “one way” channel.

they quote rfc 3264 for unicast stream for seting up the audio as one way , and for placing a stream on hold.

5.1 Unicast Streams

If the offerer wishes to only send media on a stream to its peer, it
MUST mark the stream as sendonly with the “a=sendonly” attribute.

and hold

.4 Putting a Unicast Media Stream on Hold

If a party in a call wants to put the other party “on hold”, i.e.,
request that it temporarily stops sending one or more unicast media
streams, a party offers the other an updated SDP.

If the stream to be placed on hold was previously a sendrecv media
stream, it is placed on hold by marking it as sendonly. If the
stream to be placed on hold was previously a recvonly media stream,
it is placed on hold by marking it inactive.

So they say that you cannot put the stream on hold until it has been established.
It seems to me like splitting hairs…

What do you experts think ?


Hi all,
just to keep you updated that we’ve found a possible workaround.
We set “ mohinterpret=none “ in the file /etc/asterisk/sip_general_custom.conf , and “ mohinterpret=default “ in the trunk configuration Sip -> Peer Details.
With this configuration we can now hear the remote generated busy tone and the peer remote music on hold. We’ve lost local MOH beetween two extensions, but for us it doesn’t matter.

HI, I have the same problem with my PBX. In my PBX there is asterisk and when my ISP send the message 183 with attribute a=sendonly i don’t listen the busy tone but the music on hold.

I “solved” this bug with nat=“no” in the trunk, but this is a rough patch!!! For my buisness this is a big problem!!!

I would like have real patch!!! I have see the new realease of asterisk but i don’t found the solution!

Someone has an idea?

I believe Asterisk is operating as intended. If it didn’t work this way, pressing hold on an “extension” would not result in musiconhold.

You are basically asking for a feature request, to add an option to not treat a=sendonly as hold (or to cause it to locally suppress outgoing media, without sending AST_CONTROL_HOLD, which is what turns on MoH), which means you need to ask on the developer list.

Feature requests will only, officially, get implemented in the trunk version, so it will never be officially supported on 1.8.x.x.

Hi All

I am experiencing this problem as well, I am running V12 and was wondering if there have been any developments to resolve this problem.

It seems to me that with Asterisk we have 2 functions being indicated by the same setting.

My understanding is that a=sendonly only indicates that the remote end will send but not recieve.

Asterisk seems to then automatically interpret this as call on hold, which technically seems to be incorrect.

In the case of a ‘Unavailable number’ or ‘busy number’ the remote end wants to provide information but not receive information ie - Telling the remote end that the line is busy or unavailable.

Shouldn’t we be using a=inactive or c= for a hold and enable local MOH ???

Why is Asterisk trying to read something into a=sendonly ie hold when we have the above states that mean hold.

Comments please

Thanks in Advance


a=sendonly is the de facto way of signalling hold in SIP. It is exactly how a phone would indicate hold if you pressed the hold button, or you started the enquiry in a true SIP attended transfer.

What makes this particularly difficult for Asterisk is that the sourcing MOH is done on the opposite leg of the call from the one that could either be sending its own tones, or through audio.

I understand that, except that a normal hold status is a 100/101 notify message, within the established call with an a=sendonly.
This is a 183 message, before the call is established.

It may be the de facto way of doing a hold, but the problem is that there are other uses/situations where the a=sendonly setting is used, that doesn’t mean hold.

I am still trying to work out if this is an Asterisk ‘failure to cope’ or a sip definition failure.

This must be happening for anyone with a SIP trunk where they dial a busy or unavailable number.
Otherwise, what should the upstream sip trunk provider be doing in the, busy/unavailable situation ?

Most peers providing early media do it with a=sendrecv or without any SDP.

100 is really there simply to stop retransmissions of the INVITE.

Although 183 is often associated with early media, that is not always true.

Where this one actually bites is where you have direct media, post-answer, is you can end up with both the upstream system and Asterisk generating MOH.

You would need to have a configuration option to stop Asterisk generating MOH when it got sendonly. You would have to decide whether it still needs to signal a hold to the other side of Asterisk.

As Asterisk is moving to PJSIP, you would have to see how that handles the situation, as chan_sip may not get modified in future.