This is an excerpt from rfc3264 in regards to modifying an existing session by the way:
"At any point during the session, either participant MAY issue a new offer to modify characteristics of the session. It is fundamental to the operation of the offer/answer model that the exact same offer/answer procedure defined above is used for modifying parameters of an existing session." I understand the implementation would likely be complicated -- I noticed a ticket dating back to 2005 in regards to this. I'm wondering if the user communities' demand for this functionality is enough to justify adding it to the roadmap? -Ryan On Thu, Aug 4, 2011 at 11:06 AM, Ryan McGuire <rdmcguir...@gmail.com> wrote: > > Thanks for the reply David, > I guess I don't understand an issue in implementing the offer/answer model > (rfc3264). If asterisk receives an invite and knows the egress peer's > capabilities, why not respond to the sdp in the initial invite with modified > sdp containing only g729? > So asterisk knows that it is going to dial a peer that supports only g729 > when it gets an invite from a peer that supports both ulaw and g729. Using > the offer / answer model it would look like this: > Peer -> Invite (SDP:ulaw,g729) -> Asterisk > Peer <- 100 Trying (w/ SDP -- g729 only) <- Asterisk > Peer -> 200 OK (w/ SDP g729) -> Asterisk > I understand your point about not knowing what may happen after initial call > setup, but the same implementation would apply in the event of a reinvite. > Maybe this could be an option (allow_rfc3264=yes or something of that nature). > Thanks again, > -Ryan > > On Thu, Aug 4, 2011 at 9:58 AM, David Vossel <dvos...@digium.com> wrote: >> >> ----- Original Message ----- >> > From: "Ryan McGuire" <rdmcguir...@gmail.com> >> > To: asterisk-users@lists.digium.com >> > Sent: Wednesday, August 3, 2011 9:47:42 AM >> > Subject: Re: [asterisk-users] Codec negotiation issue (no audio format >> > found to offer) >> > From looking into this, it appears as if this is due to Asterisk >> > negotiating the legs separately as if they were not related to the >> > same call. So the ingress leg negotiates ulaw, and despite it knowing >> > that the peer also supports g729 fails the call since it's already >> > decided on ulaw and the egress leg only accepts g729. >> > >> > >> > If this is design intent I'm wondering if there is demand enough to >> > justify a feature request? >> > >> > >> > Any advice on how I can work around this issue? >> > >> > >> > Thanks, >> > >> > >> > -Ryan >> >> This is a much more complicated issue than Asterisk negotiating each call >> leg separate of one another. Even if we give one call leg information about >> call setup occurring on the other call leg it is about to be bridged to, we >> are dependent on the endpoints honoring the codec preference priority we >> send them to avoid translation between one codec and another during the >> bridge... Honoring the preference order in the SDP does not always occur, >> which means that any effort in this area would only work in a perfect >> scenario. >> >> Even if we get call legs to negotiate perfectly before being bridged during >> call setup, we are not guaranteed that translation will not occur later if >> the call is transfered or parked. Regardless of what we do, if your setup >> allows ulaw and g729 for sip peers, you will always run the risk of a codec >> mixmatch... You may however be able to avoid this for some cases by using >> the sip.conf preferred_codec_only option. I believe that will limit the >> codecs negotiated during call setup to the single codec currently chosen on >> the other call leg. The problem with this is that we are not guaranteed the >> call leg supplying the codec will not change later. >> >> -- >> David Vossel >> Digium, Inc. | Software Developer, Open Source Software >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> Check us out at: www.digium.com & www.asterisk.org >> The_Boy_Wonder in #asterisk-dev >> >> -- >> _____________________________________________________________________ >> -- 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 > -- _____________________________________________________________________ -- 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
