Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
Hi Olle and co I'm really struggling to convert this into a feature request. Can anyone help? Regards, Richard -- Richard Brady T: +44 (0)7771 623 348 E: rnbr...@gmail.com 2009/4/3 Richard Brady : > Agreed Olle, it would definitely have to be option driven, not least > for backward compatibility. > > When you say "old idea", is there any discussion we can refer to? > > Exisiting variables include: > > mohinterpret > mohsuggest > musicclass > musiconhold > > The first step would be to clarify what each of these are for. Then > perhaps we can add options for those which cover the scenarios we are > interested in. > > Of course we we need to understand those scenarios too. So, let's look > at that. For each channel in the call you need to know how it holds > and how it likes to be held. > > Ways it may hold: > 1.1. a=sendonly and sends its own MOH (most likely a PBX) > 1.2. a= sendonly and expects MOH to be generated upstream (most likely > a handset) > 1.3. a=inactive and expects MOH to be generated upstream (could be PBX > or handset) > 1.4. No signalling, it will simply substitute media > > Ways it may like to be held: > 2.1. Send it a=sendonly and send it MOH (could be PBX or handset) > 2.2. Send it a= sendonly and no media (inside a network as you mentioned) > 2.3. Send it a=inactive and no media (could be PBX or handset) > 2.4. No signalling, simply send it substituted media. > > At first glance you would think that it would hold as it likes to be > held. But actually a handset could use 1.2. while expecting 2.4 as it > cannot generate hold music for either it's own user when put on hold > or the remote user when holding. > > So do we need two variables with 4 values each? I don't think so. We > only need to disambiguate between 1.1 and 1.2, and to choose between > 2.1 through 2.4. Hopefully there is some scope to narrow that down > further. I will think about it some more. > > Giving chan_sip support for the mohinterpret=passthrough option would > would be a start. But that option itself is ambiguous: does it mean > media passthrough or signalling passthrough? This ambiguity is > highlighted in the unanswered message from exvito on this list in > March last year: > > [asterisk-users] Local music on hold -- mohinterpret=passthrough assymetrical > ? > > So some thought definitely needs to go into this before it becomes a > feature request. > > R. > > > On Fri, Apr 3, 2009 at 9:03 AM, Olle E. Johansson wrote: >> My old idea was to implement an option, since there are many people >> with different opinions >> on how a PBX should behave when a channel is put on hold. >> >> An option could control how we should handle the bridged channel when >> the caller or the callee >> puts a call on hold. It could either be local hold, meaning we >> entertain the user with music, >> or a remote hold, which means that we send the hold forward over ISDN >> or SIP and let the >> other end handle the hold. This would also work well in larger >> Asterisk installations, >> where you don't want to fill up trunks between Asterisk servers with >> music. The edge server >> provides the music, no one else. >> >> In SIP we could easily add a proprietary header for music class >> suggestion in these cases. >> >> Asterisk admins should be able to set this option per call in the >> dialplan or per device in >> channel configurations - or per PBX, also in channel configs. >> >> "local hold" or "remote hold" might mean something else, coming to >> think of it. But it fitted >> in nicely here :-) >> >> /Olle >> >> 2 apr 2009 kl. 15.05 skrev Richard Brady: >> >>> Furthermore, the following two IETF documents address the need to both >>> signal the hold and provide the music: >>> >>> 1. RFC 5359 (Session Initiation Protocol Service Examples) >>> >>> 2. draft-worley-service-example-03 (Session Initiation Protocol >>> Service Example -- Music on Hold) >>> >>> Unfortunately they both address more complex scenarios and solutions, >>> but they do back me up on the fact that there are good reasons to both >>> signal hold and provide music. >>> >>> R. >>> >>> On Wed, Apr 1, 2009 at 6:16 PM, Richard Brady >>> wrote: Hi Tony I can see where you guys are coming from on this and have already enumerated your argument in my own email. But there are very real reasons for a PBX to signal the hold even when it wants to send its own MOH: 1. Bandwidth: under your scheme the PBX would continue to receive bandwidth-consuming media without using it. 2. Privacy: the far-end has an expectation of privacy while on hold and should have the option to mute automatically when held. 3. Feature richness: signalling the hold enables such innovative features such as reverse hold. 4. ISDN interworking: ISDN supports this and SIP should be compatible with that (as per standard ITU-T Q.1912.5) Also, can you explain why the PBX would use a=sendonly but not dispat
Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
Hi folks I am still thinking about the best way to fit this into the config files, but in the meantime I would like to offer some additional info in support of my argument for both signalling hold and sending MOH media. This is quoted from the SIPConnect recommendation from The SIP Forum, an industry group working towards standardisation: When the hold initiator (which may be the SIP-PBX or Service Provider network acting transparently as Media Endpoint) provides music-on-hold (MOH) treatment: - The MOH source in the SIP-PBX or SP-SSE is based on local policy. - The hold initiator MUST set the SDP directionality attribute to "a=sendonly". If the hold initiator does not provide MOH, it MUST set the SDP directionality attribute to "a=inactive" or "a=sendonly". The attribute "a=inactive" is RECOMMENDED because it provides an indication to the held entity that MOH is not being provided by the hold initiator. For more info see http://www.sipforum.org/sipconnect Regards, Richard On Fri, Apr 3, 2009 at 11:16 AM, Richard Brady wrote: > Agreed Olle, it would definitely have to be option driven, not least > for backward compatibility. > > When you say "old idea", is there any discussion we can refer to? > > Exisiting variables include: > > mohinterpret > mohsuggest > musicclass > musiconhold > > The first step would be to clarify what each of these are for. Then > perhaps we can add options for those which cover the scenarios we are > interested in. > > Of course we we need to understand those scenarios too. So, let's look > at that. For each channel in the call you need to know how it holds > and how it likes to be held. > > Ways it may hold: > 1.1. a=sendonly and sends its own MOH (most likely a PBX) > 1.2. a= sendonly and expects MOH to be generated upstream (most likely > a handset) > 1.3. a=inactive and expects MOH to be generated upstream (could be PBX > or handset) > 1.4. No signalling, it will simply substitute media > > Ways it may like to be held: > 2.1. Send it a=sendonly and send it MOH (could be PBX or handset) > 2.2. Send it a= sendonly and no media (inside a network as you mentioned) > 2.3. Send it a=inactive and no media (could be PBX or handset) > 2.4. No signalling, simply send it substituted media. > > At first glance you would think that it would hold as it likes to be > held. But actually a handset could use 1.2. while expecting 2.4 as it > cannot generate hold music for either it's own user when put on hold > or the remote user when holding. > > So do we need two variables with 4 values each? I don't think so. We > only need to disambiguate between 1.1 and 1.2, and to choose between > 2.1 through 2.4. Hopefully there is some scope to narrow that down > further. I will think about it some more. > > Giving chan_sip support for the mohinterpret=passthrough option would > would be a start. But that option itself is ambiguous: does it mean > media passthrough or signalling passthrough? This ambiguity is > highlighted in the unanswered message from exvito on this list in > March last year: > > [asterisk-users] Local music on hold -- mohinterpret=passthrough assymetrical > ? > > So some thought definitely needs to go into this before it becomes a > feature request. > > R. > > > On Fri, Apr 3, 2009 at 9:03 AM, Olle E. Johansson wrote: >> My old idea was to implement an option, since there are many people >> with different opinions >> on how a PBX should behave when a channel is put on hold. >> >> An option could control how we should handle the bridged channel when >> the caller or the callee >> puts a call on hold. It could either be local hold, meaning we >> entertain the user with music, >> or a remote hold, which means that we send the hold forward over ISDN >> or SIP and let the >> other end handle the hold. This would also work well in larger >> Asterisk installations, >> where you don't want to fill up trunks between Asterisk servers with >> music. The edge server >> provides the music, no one else. >> >> In SIP we could easily add a proprietary header for music class >> suggestion in these cases. >> >> Asterisk admins should be able to set this option per call in the >> dialplan or per device in >> channel configurations - or per PBX, also in channel configs. >> >> "local hold" or "remote hold" might mean something else, coming to >> think of it. But it fitted >> in nicely here :-) >> >> /Olle >> >> 2 apr 2009 kl. 15.05 skrev Richard Brady: >> >>> Furthermore, the following two IETF documents address the need to both >>> signal the hold and provide the music: >>> >>> 1. RFC 5359 (Session Initiation Protocol Service Examples) >>> >>> 2. draft-worley-service-example-03 (Session Initiation Protocol >>> Service Example -- Music on Hold) >>> >>> Unfortunately they both address more complex scenarios and solutions, >>> but they do back me up on the fact that there are good reasons to both >>> signal hold and provide music. >>> >>> R. >>> >>> On Wed, Apr 1, 2009 at 6:16
Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
Agreed Olle, it would definitely have to be option driven, not least for backward compatibility. When you say "old idea", is there any discussion we can refer to? Exisiting variables include: mohinterpret mohsuggest musicclass musiconhold The first step would be to clarify what each of these are for. Then perhaps we can add options for those which cover the scenarios we are interested in. Of course we we need to understand those scenarios too. So, let's look at that. For each channel in the call you need to know how it holds and how it likes to be held. Ways it may hold: 1.1. a=sendonly and sends its own MOH (most likely a PBX) 1.2. a= sendonly and expects MOH to be generated upstream (most likely a handset) 1.3. a=inactive and expects MOH to be generated upstream (could be PBX or handset) 1.4. No signalling, it will simply substitute media Ways it may like to be held: 2.1. Send it a=sendonly and send it MOH (could be PBX or handset) 2.2. Send it a= sendonly and no media (inside a network as you mentioned) 2.3. Send it a=inactive and no media (could be PBX or handset) 2.4. No signalling, simply send it substituted media. At first glance you would think that it would hold as it likes to be held. But actually a handset could use 1.2. while expecting 2.4 as it cannot generate hold music for either it's own user when put on hold or the remote user when holding. So do we need two variables with 4 values each? I don't think so. We only need to disambiguate between 1.1 and 1.2, and to choose between 2.1 through 2.4. Hopefully there is some scope to narrow that down further. I will think about it some more. Giving chan_sip support for the mohinterpret=passthrough option would would be a start. But that option itself is ambiguous: does it mean media passthrough or signalling passthrough? This ambiguity is highlighted in the unanswered message from exvito on this list in March last year: [asterisk-users] Local music on hold -- mohinterpret=passthrough assymetrical ? So some thought definitely needs to go into this before it becomes a feature request. R. On Fri, Apr 3, 2009 at 9:03 AM, Olle E. Johansson wrote: > My old idea was to implement an option, since there are many people > with different opinions > on how a PBX should behave when a channel is put on hold. > > An option could control how we should handle the bridged channel when > the caller or the callee > puts a call on hold. It could either be local hold, meaning we > entertain the user with music, > or a remote hold, which means that we send the hold forward over ISDN > or SIP and let the > other end handle the hold. This would also work well in larger > Asterisk installations, > where you don't want to fill up trunks between Asterisk servers with > music. The edge server > provides the music, no one else. > > In SIP we could easily add a proprietary header for music class > suggestion in these cases. > > Asterisk admins should be able to set this option per call in the > dialplan or per device in > channel configurations - or per PBX, also in channel configs. > > "local hold" or "remote hold" might mean something else, coming to > think of it. But it fitted > in nicely here :-) > > /Olle > > 2 apr 2009 kl. 15.05 skrev Richard Brady: > >> Furthermore, the following two IETF documents address the need to both >> signal the hold and provide the music: >> >> 1. RFC 5359 (Session Initiation Protocol Service Examples) >> >> 2. draft-worley-service-example-03 (Session Initiation Protocol >> Service Example -- Music on Hold) >> >> Unfortunately they both address more complex scenarios and solutions, >> but they do back me up on the fact that there are good reasons to both >> signal hold and provide music. >> >> R. >> >> On Wed, Apr 1, 2009 at 6:16 PM, Richard Brady >> wrote: >>> Hi Tony >>> >>> I can see where you guys are coming from on this and have already >>> enumerated your argument in my own email. >>> >>> But there are very real reasons for a PBX to signal the hold even >>> when >>> it wants to send its own MOH: >>> >>> 1. Bandwidth: under your scheme the PBX would continue to receive >>> bandwidth-consuming media without using it. >>> 2. Privacy: the far-end has an expectation of privacy while on hold >>> and should have the option to mute automatically when held. >>> 3. Feature richness: signalling the hold enables such innovative >>> features such as reverse hold. >>> 4. ISDN interworking: ISDN supports this and SIP should be compatible >>> with that (as per standard ITU-T Q.1912.5) >>> >>> Also, can you explain why the PBX would use a=sendonly but not >>> dispatch media. Why not a=inactive for that case? >>> IMHO, PBX-A would be broken if it passed this along the Hold message to downstream and then started servicing the MOH itself >>> >>> Remember it is not a hold message, it is a media attribute and we are >>> discussing how that should be interpreted within the context of the >>> hold feature in traditional telephony. >
Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
My old idea was to implement an option, since there are many people with different opinions on how a PBX should behave when a channel is put on hold. An option could control how we should handle the bridged channel when the caller or the callee puts a call on hold. It could either be local hold, meaning we entertain the user with music, or a remote hold, which means that we send the hold forward over ISDN or SIP and let the other end handle the hold. This would also work well in larger Asterisk installations, where you don't want to fill up trunks between Asterisk servers with music. The edge server provides the music, no one else. In SIP we could easily add a proprietary header for music class suggestion in these cases. Asterisk admins should be able to set this option per call in the dialplan or per device in channel configurations - or per PBX, also in channel configs. "local hold" or "remote hold" might mean something else, coming to think of it. But it fitted in nicely here :-) /Olle 2 apr 2009 kl. 15.05 skrev Richard Brady: > Furthermore, the following two IETF documents address the need to both > signal the hold and provide the music: > > 1. RFC 5359 (Session Initiation Protocol Service Examples) > > 2. draft-worley-service-example-03 (Session Initiation Protocol > Service Example -- Music on Hold) > > Unfortunately they both address more complex scenarios and solutions, > but they do back me up on the fact that there are good reasons to both > signal hold and provide music. > > R. > > On Wed, Apr 1, 2009 at 6:16 PM, Richard Brady > wrote: >> Hi Tony >> >> I can see where you guys are coming from on this and have already >> enumerated your argument in my own email. >> >> But there are very real reasons for a PBX to signal the hold even >> when >> it wants to send its own MOH: >> >> 1. Bandwidth: under your scheme the PBX would continue to receive >> bandwidth-consuming media without using it. >> 2. Privacy: the far-end has an expectation of privacy while on hold >> and should have the option to mute automatically when held. >> 3. Feature richness: signalling the hold enables such innovative >> features such as reverse hold. >> 4. ISDN interworking: ISDN supports this and SIP should be compatible >> with that (as per standard ITU-T Q.1912.5) >> >> Also, can you explain why the PBX would use a=sendonly but not >> dispatch media. Why not a=inactive for that case? >> >>> IMHO, PBX-A would be broken if it passed this along the Hold >>> message to downstream and then started servicing the MOH itself >> >> Remember it is not a hold message, it is a media attribute and we are >> discussing how that should be interpreted within the context of the >> hold feature in traditional telephony. >> >> I would also like to point out in my defence that there are several >> telephone systems in the field which behave as I described (Nortel >> BCM50, Aastra Intelligate, Mitel 3300 to name a few). >> >> Regards, >> Richard >> >> >>> I have to agree with Kevin on this one. >>> >>> I fail to understand how you have a PBX-A talking to Asterisk >>> talking to PBX-B and the PBX-A placing the call on hold. >>> Typically you should have a Client/Phone to PBX-A to Asterisk to >>> PBX-B to Client/Phone/VoiceMail. >>> >>> If the Client signals Hold, the PBX should NOT be passing that >>> Hold status on but transition audio stream from Client to MOH >>> (assuming MOH is handled). Asterisk shouldn't notice a thing >>> except more RTP packets (or less if it is my teenage daughter on >>> the phone as the case may be). >>> >>> IMHO, PBX-A would be broken if it passed this along the Hold >>> message to downstream and then started servicing the MOH itself on >>> the RTP stream. That just doesn't make sense. >>> >>> Now if PBX-A were not a PBX and were a SIP Router, and the SIP >>> Router was attempting this, I can see how it would Re-Invite, but >>> it shouldn't pass the hold status onto Asterisk. >>> >>> Need some clarity here. >>> >>> Tony Plack >> > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users --- * Olle E Johansson - o...@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
Furthermore, the following two IETF documents address the need to both signal the hold and provide the music: 1. RFC 5359 (Session Initiation Protocol Service Examples) 2. draft-worley-service-example-03 (Session Initiation Protocol Service Example -- Music on Hold) Unfortunately they both address more complex scenarios and solutions, but they do back me up on the fact that there are good reasons to both signal hold and provide music. R. On Wed, Apr 1, 2009 at 6:16 PM, Richard Brady wrote: > Hi Tony > > I can see where you guys are coming from on this and have already > enumerated your argument in my own email. > > But there are very real reasons for a PBX to signal the hold even when > it wants to send its own MOH: > > 1. Bandwidth: under your scheme the PBX would continue to receive > bandwidth-consuming media without using it. > 2. Privacy: the far-end has an expectation of privacy while on hold > and should have the option to mute automatically when held. > 3. Feature richness: signalling the hold enables such innovative > features such as reverse hold. > 4. ISDN interworking: ISDN supports this and SIP should be compatible > with that (as per standard ITU-T Q.1912.5) > > Also, can you explain why the PBX would use a=sendonly but not > dispatch media. Why not a=inactive for that case? > >> IMHO, PBX-A would be broken if it passed this along the Hold message to >> downstream and then started servicing the MOH itself > > Remember it is not a hold message, it is a media attribute and we are > discussing how that should be interpreted within the context of the > hold feature in traditional telephony. > > I would also like to point out in my defence that there are several > telephone systems in the field which behave as I described (Nortel > BCM50, Aastra Intelligate, Mitel 3300 to name a few). > > Regards, > Richard > > >> I have to agree with Kevin on this one. >> >> I fail to understand how you have a PBX-A talking to Asterisk talking to >> PBX-B and the PBX-A placing the call on hold. Typically you should have a >> Client/Phone to PBX-A to Asterisk to PBX-B to Client/Phone/VoiceMail. >> >> If the Client signals Hold, the PBX should NOT be passing that Hold status >> on but transition audio stream from Client to MOH (assuming MOH is handled). >> Asterisk shouldn't notice a thing except more RTP packets (or less if it is >> my teenage daughter on the phone as the case may be). >> >> IMHO, PBX-A would be broken if it passed this along the Hold message to >> downstream and then started servicing the MOH itself on the RTP stream. >> That just doesn't make sense. >> >> Now if PBX-A were not a PBX and were a SIP Router, and the SIP Router was >> attempting this, I can see how it would Re-Invite, but it shouldn't pass the >> hold status onto Asterisk. >> >> Need some clarity here. >> >> Tony Plack > ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
Hi Tony I can see where you guys are coming from on this and have already enumerated your argument in my own email. But there are very real reasons for a PBX to signal the hold even when it wants to send its own MOH: 1. Bandwidth: under your scheme the PBX would continue to receive bandwidth-consuming media without using it. 2. Privacy: the far-end has an expectation of privacy while on hold and should have the option to mute automatically when held. 3. Feature richness: signalling the hold enables such innovative features such as reverse hold. 4. ISDN interworking: ISDN supports this and SIP should be compatible with that (as per standard ITU-T Q.1912.5) Also, can you explain why the PBX would use a=sendonly but not dispatch media. Why not a=inactive for that case? > IMHO, PBX-A would be broken if it passed this along the Hold message to > downstream and then started servicing the MOH itself Remember it is not a hold message, it is a media attribute and we are discussing how that should be interpreted within the context of the hold feature in traditional telephony. I would also like to point out in my defence that there are several telephone systems in the field which behave as I described (Nortel BCM50, Aastra Intelligate, Mitel 3300 to name a few). Regards, Richard > I have to agree with Kevin on this one. > > I fail to understand how you have a PBX-A talking to Asterisk talking to > PBX-B and the PBX-A placing the call on hold. Typically you should have a > Client/Phone to PBX-A to Asterisk to PBX-B to Client/Phone/VoiceMail. > > If the Client signals Hold, the PBX should NOT be passing that Hold status on > but transition audio stream from Client to MOH (assuming MOH is handled). > Asterisk shouldn't notice a thing except more RTP packets (or less if it is > my teenage daughter on the phone as the case may be). > > IMHO, PBX-A would be broken if it passed this along the Hold message to > downstream and then started servicing the MOH itself on the RTP stream. That > just doesn't make sense. > > Now if PBX-A were not a PBX and were a SIP Router, and the SIP Router was > attempting this, I can see how it would Re-Invite, but it shouldn't pass the > hold status onto Asterisk. > > Need some clarity here. > > Tony Plack ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
> Ok, this is where it gets interesting. Consider the case of a PBX > which has its own MOH source and is talking via Asterisk to another > PBX. > > If that PBX wants to put the call on hold while sending its own MOH, > you would probably argue that it should not send a re-INIVTE at all, > but should simply replace the outbound audio stream with its MOH and > discard the inbound audio stream. I have to agree with Kevin on this one. I fail to understand how you have a PBX-A talking to Asterisk talking to PBX-B and the PBX-A placing the call on hold. Typically you should have a Client/Phone to PBX-A to Asterisk to PBX-B to Client/Phone/VoiceMail. If the Client signals Hold, the PBX should NOT be passing that Hold status on but transition audio stream from Client to MOH (assuming MOH is handled). Asterisk shouldn't notice a thing except more RTP packets (or less if it is my teenage daughter on the phone as the case may be). IMHO, PBX-A would be broken if it passed this along the Hold message to downstream and then started servicing the MOH itself on the RTP stream. That just doesn't make sense. Now if PBX-A were not a PBX and were a SIP Router, and the SIP Router was attempting this, I can see how it would Re-Invite, but it shouldn't pass the hold status onto Asterisk. Need some clarity here. Tony Plack ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
Ok, this is where it gets interesting. Consider the case of a PBX which has its own MOH source and is talking via Asterisk to another PBX. If that PBX wants to put the call on hold while sending its own MOH, you would probably argue that it should not send a re-INIVTE at all, but should simply replace the outbound audio stream with its MOH and discard the inbound audio stream. But there are motivations for signalling that the call is on hold (bandwidth, or ISDN interworking for example) so if the PBX wants to, it should be able to. If it sends a re-INVITE with a=sendonly in the SDP, that is an explicit indication that it is going to continue to send media but is not interested in receiving any. It is reasonable then to assume that the media which it continues to send is its MOH. So I would disagree with the statement that "placing you on hold and sending you a media stream, that is broken". The counter argument to mine is that there are scenarios where the endpoint (usually a handset) needs to signal that the call is on hold in such a way that Asterisk knows to insert MOH. Currently this might be done with the a=sendonly mechanism, which makes this scenario incompatible with the one I describe above due to ambiguity of the a=sendonly line. In response to this I would say the correct way for such an endpoint to signal hold is with a=inactive, as the handset is neither producing nor consuming media during the hold. The PBX (Asterisk) then has the option to pass on the a=inactive to the other endpoint or to renegotiate for the insertion of local MOH. I am not sure whether the current convention for handsets is a=sendonly or a=inactive but I'm hoping it's the latter. In any case, because MOH is often used for marketing, corporate identity or just to irritate people, there is a need to get the scenario above working. How could we go about that? On Tue, Mar 31, 2009 at 12:45 PM, Kevin P. Fleming wrote: > Richard Brady wrote: > >> I have researched the musiconhold / musicclass options in sip.conf as >> well as the various documented classes and modes within >> musiconhold.conf but I can't see how I tell it to just relay the media >> stream straight on. > > Well, first, I was mistaken, and support for this behavior (passing > through the 'hold' signaling) has not in fact been added to chan_sip.c > yet, although it is supported in chan_iax2.c. > > However, your last comment here doesn't make sense: if the remote party > put you on hold, there shouldn't be any media stream to 'relay' from it. > That's why we normally replace the missing media stream with locally > generated MOH. When (if) chan_sip is enhanced to support the > 'mohinterpret=passthrough' setting like chan_iax2 has, then instead we'd > pass on the 'hold' signaling to the SIP endpoint that was placed on > hold, instead of sending it MOH. What it chooses to do to present that > hold state to its user (or farther endpoint, if it is another B2BUA) is > up to it, but in any case, there is no media stream to pass to it. > > If you have an endpoint that is *both* placing you on hold and sending > you a media stream, that is broken. We don't have any concept of 'hold > with media' in Asterisk today. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kpflem...@digium.com > Check us out at www.digium.com & www.asterisk.org > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
Richard Brady wrote: > I have researched the musiconhold / musicclass options in sip.conf as > well as the various documented classes and modes within > musiconhold.conf but I can't see how I tell it to just relay the media > stream straight on. Well, first, I was mistaken, and support for this behavior (passing through the 'hold' signaling) has not in fact been added to chan_sip.c yet, although it is supported in chan_iax2.c. However, your last comment here doesn't make sense: if the remote party put you on hold, there shouldn't be any media stream to 'relay' from it. That's why we normally replace the missing media stream with locally generated MOH. When (if) chan_sip is enhanced to support the 'mohinterpret=passthrough' setting like chan_iax2 has, then instead we'd pass on the 'hold' signaling to the SIP endpoint that was placed on hold, instead of sending it MOH. What it chooses to do to present that hold state to its user (or farther endpoint, if it is another B2BUA) is up to it, but in any case, there is no media stream to pass to it. If you have an endpoint that is *both* placing you on hold and sending you a media stream, that is broken. We don't have any concept of 'hold with media' in Asterisk today. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com & www.asterisk.org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
Kevin That's great to hear. I'm using 1.4.21.2, but I can't see where or how it's configurable. I have researched the musiconhold / musicclass options in sip.conf as well as the various documented classes and modes within musiconhold.conf but I can't see how I tell it to just relay the media stream straight on. Any help greatly appreciated. Richard On Mon, Mar 30, 2009 at 9:04 PM, Kevin P. Fleming wrote: > Richard Brady wrote: > >> If Asterisk is bridging a call between two SIP peers and one peer puts >> the other on hold by means of a re-INVITE with SDP containing >> a=sendonly, Asterisk will play locally generated MOH instead of >> relaying the media streamed by the SIP peer which took the hold >> action. >> >> Any ideas how to change that? > > What version of Asterisk are you using? If it's 1.4 or later, this > already configurable in sip.conf. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kpflem...@digium.com > Check us out at www.digium.com & www.asterisk.org > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk doesn't relay remote MOH during hold
Richard Brady wrote: > If Asterisk is bridging a call between two SIP peers and one peer puts > the other on hold by means of a re-INVITE with SDP containing > a=sendonly, Asterisk will play locally generated MOH instead of > relaying the media streamed by the SIP peer which took the hold > action. > > Any ideas how to change that? What version of Asterisk are you using? If it's 1.4 or later, this already configurable in sip.conf. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com & www.asterisk.org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
