I am sure I submitted the following "alternative" behaviour to the bug-tracker in the past, but cannot find any reference to it. Here is the patch I use to IMHO improve this behaviour.
In case it is not officially uploaded, I will state here that this code is "disclaimed" and "unencumbered" as if uploaded to JIRA. Regards, Steve On 15 July 2013 17:20, Hristo Trendev <dist.li...@gmail.com> wrote: > I think I have found the answer to my questions in the source code of Dial: > > case AST_CONTROL_PROGRESS: > ast_verb(3, "%s is making progress passing it to %s\n", > ast_channel_name(c), ast_channel_name(in)); > /* Setup early media if appropriate */ > if (single && !caller_entertained > && CAN_EARLY_BRIDGE(peerflags, in, c)) { > ast_channel_early_bridge(in, c); > } > if (!ast_test_flag64(outgoing, OPT_RINGBACK)) { > if (single || (!single && !pa->sentringing)) { > ast_indicate(in, AST_CONTROL_PROGRESS); > } > } > > ..... > ..... > > > Asterisk will attempt to bridge the media only for the case of a single > outgoing channel, but at the same time it will happily forward progress > messages for parallel calls: (!single && !pa->sentringing) as long as no 180 > Ringing message was sent out to the caller yet. The questions still remains > if this should be reported as bug or if there is indeed a use case when > sending 183 progress message, without actually bridging the media stream is > desired. > > > > On Mon, Jul 15, 2013 at 4:14 PM, Hristo Trendev <dist.li...@gmail.com>wrote: > >> Hi, >> I am using asterisk 1.8.22 and have a problem when calling in parallel >> several SIP endpoints and I am not sure how to resolve it. In this case >> Asterisk will not bridge any audio to the caller before the 200 OK. Which >> means any progress announcements, including remotely generated ringback, >> are not passed back to the caller. >> >> This behavior is completely correct, because there is no way to know >> which early media audio stream to pass back to the caller in a parallel >> call scenario (as in this case several endpoint may indicate session >> progress all at the same time). >> >> The question is why is asterisk still sending 183 session progress back >> to the caller if no audio is to be bridged before the 200 OK anyway? If 183 >> are not passed back to the caller, then at least a 180 Ringing that may >> come from another endpoint will cause the calling endpoint to generate >> local ringback. This won't happen if the caller has received a 183 already. >> >> So it's a bit of a race condition as well - if the first endpoint to >> reply sends a "183 session progress" this means the caller will not hear >> any ringback even if some of the other endpoints are sending back 180 >> Ringing. >> >> The question is can I somehow block 183 messages from being passed back >> to the calling endpoint when dialing several destinations in parallel? I >> don't see a point (please correct me if I'm wrong) to pass only the 183 SIP >> message back to the caller without the corresponding RTP stream, so it may >> be much better to actually ignore it when dealing with parallel call >> scenarios (bug?). >> >> BR, >> Hristo >> > > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
multiple_early_media
Description: Binary data
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users