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 rnbr...@gmail.com: 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 o...@edvina.net 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 rnbr...@gmail.com 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
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: quote 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. quote/ For more info see http://www.sipforum.org/sipconnect Regards, Richard On Fri, Apr 3, 2009 at 11:16 AM, Richard Brady rnbr...@gmail.com 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 o...@edvina.net 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 rnbr...@gmail.com wrote: Hi Tony I can see where you guys are coming from on this and have already enumerated your
Re: [asterisk-users] Local music on hold -- mohinterpret=passthrough assymetrical ?
Exvito Did you ever make any progress on this? Richard On Mon, Mar 10, 2008 at 2:38 AM, Ex Vito ex.vitor...@gmail.com wrote: Hi list, I'm planning and testing a distributed asterisk deployment throughout several sites; each will be connected to the PSTN and all of them among themselves via IAX trunks. Phones will be SIP. I guess I already solved (worked-around, actually) asterisk's codec negotiation limitations regarding local G.711 utilization vs. remote G.729 while minimizing transcoding -- a bit of dial plan tweaking via the setting of SIP_CODEC variable seems to do the trick. But I digress... (with patch in issue 4825 things would be much nicer!) Now I'm still trying to improve bandwith usage with local music on hold; that is, when sip user A1, registered to server A puts sip caller B1, registered to server B, caller B1 gets server B's music on hold -- this removes the need of streaming audio from server A to server B while B1 is on hold, which in my scenario is a good thing. I post to the list trying to get peer feedback to my initial tests. The configurations I mention are always applied to both servers A and B. 1. If I set mohinterpret=passthrough + mohsuggest=default in the [general] section of iax.conf the local music on hold never works. Results: bad - A1 calls B1, B1 puts A1 on hold, A1 gets B's music bad - A1 calls B1, A1 puts B1 on hold, B1 gets A's music bad - B1 calls A1, A1 puts B1 on hold, B1 gets A's music bad - B1 calls A1, B1 puts A1 on hold, A1 gets B's music 2. If I set mohinterpret=passthrough + mohsuggest=default in the specific peer/user (friend, actually) section I get improved results but not perfect (or, at least, as I'd like them to be). Results: good - A1 calls B1, B1 puts A1 on hold, A1 gets A's music bad - A1 calls B1, A1 puts B1 on hold, B1 gets A's music good - B1 calls A1, A1 puts B1 on hold, B1 gets B's music bad - B1 calls A1, B1 puts A1 on hold, A1 gets B's music Fortunatelly, the good cases seem to be the most plausible ones. So, in my observation, the mohinterpret=passthrough behaviour is not symmetrical; that is, the hold signalling only seems to travel one way along the IAX trunk... From the side receiving the call to the side initiating it, and not the other way around. Can anyone verify this behaviour ? Am I doing something wrong or is this expected / by design behaviour ? Should I file a bug against 1. ? Against 2. ? Extra points question: Since the calls in this case are remote, from site A to site B, the codec in use is G.729 which, as you might well know, is really awfull at supporting music since it's been designed for voice only. How would one have the RTP stream renegotiated during call to G.711 when entering music on hold (local, of course, after fixing my issues above!) and back to G.729 when back to conversation ? (ok, this probably needs patching the source !... but maybe someone has an idea or has taken a different approach at this...) :-) Thanks a lot for any feedback, -- exvito ___ -- 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
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 o...@edvina.net 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 rnbr...@gmail.com 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
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 rnbr...@gmail.com 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
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 kpflem...@digium.com 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
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 kpflem...@digium.com 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
[asterisk-users] Asterisk doesn't relay remote MOH during hold
Hi all 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? (This is understandable if the peer is a handset but can be a problem if it is a PBX with its own MOH source.) Richard -- Richard Brady ___ -- 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] Channel variable to identify the calling SIP peer
Thanks Grey and Philipp Parsing the channel name is what we have been doing, but this has an unfortunate dependence on username as opposed to peer name. The username property of a SIP peer is not very well documented, and when using realtime SIP, it's an immutable field once loaded into cache. So I look forward to the day we can upgrade! Richard On Sun, Nov 30, 2008 at 6:47 PM, Philipp Kempgen [EMAIL PROTECTED]wrote: Grey Man schrieb: On Wed, Nov 26, 2008 at 11:47 AM, Richard Brady [EMAIL PROTECTED] wrote: Hi folks I'm not sure what I am missing but I cannot find a predefined channel variable to identify the SIP peer/user which has initiated a call and established the channel. The one option is to extract it from the CHANNEL variable, but that is fraught with difficulties. Is there another variable I don't know about or another way to do this? In 1.2 and 1.4 I don't believe there is any other way. Parsing the username from the channel name is what we ended up having to do! Since 1.6 there is CHANNEL(peername). Philipp Kempgen -- http://www.das-asterisk-buch.de - http://www.the-asterisk-book.com Amooma GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998 -- ___ -- 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
[asterisk-users] Channel variable to identify the calling SIP peer
Hi folks I'm not sure what I am missing but I cannot find a predefined channel variable to identify the SIP peer/user which has initiated a call and established the channel. The one option is to extract it from the CHANNEL variable, but that is fraught with difficulties. Is there another variable I don't know about or another way to do this? Thanks in advance! Richard -- Richard Brady T: +44 (0)7771 623 348 E: [EMAIL PROTECTED] ___ -- 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] Forcing repacketization on SIP to SIP call
JT Once again thanks for the help on this. I have found the issue, which was, as they say, carbon based. I was getting mixed up because the default setting allow=alaw, is displayed as follows when I do sip show user : Codec Order : (ulaw:20,alaw:20,g729:20) which I thought was equivalent to having allow=alaw:20, but it is not. Setting the ACLs to alaw:20 explicitly as you described has fixed this issue. W.r.t. you comment: and in the SDP Asterisk should offer a ptime and maxptime I must add that I could not get Asterisk to send a maxptime in the SDP, nor can I find any instance of maxptime in the Asterisk source code (version 1.4.18 so it may have since been added). Thanks again! Richard On Tue, Nov 11, 2008 at 11:29 AM, Richard Brady [EMAIL PROTECTED] wrote: JT Thanks for this detailed response. It's clear I have some more homework to do before going anywhere near Mantis, but I will follow up either way. Regards, Richard On Tue, Oct 28, 2008 at 9:02 PM, John Todd [EMAIL PROTECTED] wrote: This seems like a transcoding issue, and the RTP code may not be clever enough to understand that a repacketization is transcoding and therefore lets the media flow directly and/or passes the RTP packets through without examining or modifying them. This could be an error in the way RTP transcoding is handled - put on your superhero bugtracking cape and post to Mantis! I'd suggest that you document this clearly, and put it on the bugs.digium.com system if you've tried all possible iterations of allow= and deny= for getting this media to transcode. It would seem that alaw:20 is different than alaw:40, and if you've found that they are treated as equal then there seems to be a problem. While not explicitly stated in the doc/rtp-packetization.txt file, it does seem that several things are true: - it seems that if a remote sender is sending 40ms packets, and you have not explicitly denied 40ms packets, that Asterisk should accept those packets. This seems to work. - if you explicitly have deny=all and then allow=alaw:20 in a peer definition, it should be the case that Asterisk takes whatever audio stream and transcode it for the remote peer in that format (and in the SDP Asterisk should offer a ptime and maxptime based on the default and highest ptime acceptable, in this case 20 for both.) Is this broken? - if a remote host sends you a ptime that is not defined or defaulted in the list of allow= codec choices for that peer (or globally) then the call should be refused just like it would be with any other codec mismatch. (Of course, if you don't have a deny=all as the first statement in your peer codec list, Asterisk should let anything through since that's the way those ACLs work. I mention this only as a caution for reporting problems that might not be problems.) Is this broken? This problem is actually fairly important when we start talking about scale. All RTP-based systems start to experience bottlenecks introduced by Packets-Per-Second limits on hardware interfaces. The upper limit of performance starts to be more bound to throughput on interfaces and kernel drivers, rather than in the higher-layer code. PPS, not megabits per second, becomes the number to beat. If you can get RTP packets to go from 20ms to 40ms, it doubles the size of the packet and effectively halves the number of packets you're sending on your interface, which _could_ lead to doubling of total numbers of calls as the limits of interface buffering are reached in the near future. Even if you're just doing this on one leg of a looped call, this still could reduce your overall PPS by 25%, which is nothing to sniff at. Of course, I'm assuming that the load introduced by re- packetizing different packet delays is not significant - this could be a false assumption. JT --- John Todd [EMAIL PROTECTED]+1-256-428-6083 Asterisk Open Source Community Director ___ -- 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] Forcing repacketization on SIP to SIP call
JT Thanks for this detailed response. It's clear I have some more homework to do before going anywhere near Mantis, but I will follow up either way. Regards, Richard On Tue, Oct 28, 2008 at 9:02 PM, John Todd [EMAIL PROTECTED] wrote: This seems like a transcoding issue, and the RTP code may not be clever enough to understand that a repacketization is transcoding and therefore lets the media flow directly and/or passes the RTP packets through without examining or modifying them. This could be an error in the way RTP transcoding is handled - put on your superhero bugtracking cape and post to Mantis! I'd suggest that you document this clearly, and put it on the bugs.digium.com system if you've tried all possible iterations of allow= and deny= for getting this media to transcode. It would seem that alaw:20 is different than alaw:40, and if you've found that they are treated as equal then there seems to be a problem. While not explicitly stated in the doc/rtp-packetization.txt file, it does seem that several things are true: - it seems that if a remote sender is sending 40ms packets, and you have not explicitly denied 40ms packets, that Asterisk should accept those packets. This seems to work. - if you explicitly have deny=all and then allow=alaw:20 in a peer definition, it should be the case that Asterisk takes whatever audio stream and transcode it for the remote peer in that format (and in the SDP Asterisk should offer a ptime and maxptime based on the default and highest ptime acceptable, in this case 20 for both.) Is this broken? - if a remote host sends you a ptime that is not defined or defaulted in the list of allow= codec choices for that peer (or globally) then the call should be refused just like it would be with any other codec mismatch. (Of course, if you don't have a deny=all as the first statement in your peer codec list, Asterisk should let anything through since that's the way those ACLs work. I mention this only as a caution for reporting problems that might not be problems.) Is this broken? This problem is actually fairly important when we start talking about scale. All RTP-based systems start to experience bottlenecks introduced by Packets-Per-Second limits on hardware interfaces. The upper limit of performance starts to be more bound to throughput on interfaces and kernel drivers, rather than in the higher-layer code. PPS, not megabits per second, becomes the number to beat. If you can get RTP packets to go from 20ms to 40ms, it doubles the size of the packet and effectively halves the number of packets you're sending on your interface, which _could_ lead to doubling of total numbers of calls as the limits of interface buffering are reached in the near future. Even if you're just doing this on one leg of a looped call, this still could reduce your overall PPS by 25%, which is nothing to sniff at. Of course, I'm assuming that the load introduced by re- packetizing different packet delays is not significant - this could be a false assumption. JT --- John Todd [EMAIL PROTECTED]+1-256-428-6083 Asterisk Open Source Community Director ___ -- 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
[asterisk-users] Forcing repacketization on SIP to SIP call
Hi folks I have a handset talking to Asterisk, which in turn puts the call through to an ITSP. The handsets likes to send audio in 40ms frames (even though Asterisk requests 20ms frames with a ptime header in the SDP). The ITSP doesn't request any particular frame length (with ptime) or state a maximum length (with maxptime), so when Asterisk receives the 40ms media frames from the handset, it simply relays it on to the ITSP. Unfortunately the ITSP doesn't support this, and the result is one-way audio. I would like to know whether there is a way to force Asterisk to repacketize the media stream, converting from 40ms frames to 20ms frames. I am aware of the allow=alaw:20 syntax but this doesn't seem to work. It is not clear from the docs whether that setting is for the SDP offer (in which case it would only affect incoming media) or whether it's used to to actually force what is sent to a peer/user as well (in which case it is not behaving as expected). I would also be interested to know what the correct action is for the ITSP to take. How do they complain (using SIP and/or SDP) that the media received is not what they were expecting? Any help would be greatly appreciated. Regards, Richard -- Richard Brady T: +44 (0)7771 623 348 E: [EMAIL PROTECTED] ___ -- 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] Turn off SIP 183 Session Progress in Asterisk 1.4.8
Hi Andrew Thanks for your response. Yes, the option is progressinband in sip.conf As far as I can tell, the progressinband setting does not prevent the 183 from being sent altogether. For example, with progressinband=never, early audio from UA1 to UA2 after a 180 ringing will still trigger a 183 from UA2 to UA3. Why do you care about the 183 or not? The 183 message exercises a bug in the software used by a certain ITSP, whereby ring-back continues to be heard by a PSTN caller after the call is established with 200 OK. Disabling the 183 would be an effective temporary workaround. Also it wouldnt hurt to read the SIP RFC's to have a better understanding of what is going on: Thanks for the links, I have read these documents. Is there something I appear not to understand? Regards, Richard -- Richard Brady T: +44 (0)7771 623 348 E: [EMAIL PROTECTED] ___ --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
[asterisk-users] Turn off SIP 183 Session Progress in Asterisk 1.4.8
[Resent due to non-descriptive subject line.] Hi folks When connecting two SIP users, is there any way to stop Asterisk from sending SIP 183 Session Progress messages, either globally or per-peer? Scenario as follows: Call from UA1 to Asterisk (UA2) to UA3. UA3 sends RTP before SIP OK to Asterisk (UA2). Asterisk (UA2) detects early audio from UA3 and sends 183 Session Progress with SDP to UA1. Instead I would like it to just send on the early audio, is this possible? Thanks in advance, Richard ___ --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] Welcome to the asterisk-users mailing list (Digest mode)
Hi folks When connecting two SIP users, is there any way to stop Asterisk from sending SIP 183 Session Progress messages, either globally or per-peer? Call from UA1 to Asterisk (UA2) to UA3 UA3 sends RTP before SIP OK to Asterisk (UA2) Asterisk (UA2) detects early audio from UA3 and sends 183 Session Progress with SDP to UA1. Instead I would like it to just send on the early audio, is this possible? Thanks in advance, Richard ___ --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] Welcome to the asterisk-users mailing list (Digest mode)
Hi Alex Apologies for that, I noticed this immediately after I sent the email and resent it with fresh headers and a descriptive subject line. I will be more careful in future. Regards, Richard -- Richard Brady T: +44 (0)7771 623 348 E: [EMAIL PROTECTED] ___ --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
