Send BYE, you might want to include the warning/error header in the BYE. Madhav
On Thu, Mar 20, 2008 at 8:36 AM, <[EMAIL PROTECTED]> wrote: > Thanks for Ramprakash's nice input. Do you have any ideas on the > behaviors on that how a UA inteacts with the 3pcc under a error > scenario, as what I have be concerned with that the ACK carries a > mismatch codec value to answer the 200ok(SDP offer). > > > Alex Zhang > ESN: 6-554-8782 > > > > ________________________________ > > From: Ramprakash V [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 19, 2008 3:00 PM > To: Alex Zhang (GDNTRND); [EMAIL PROTECTED]; [EMAIL PROTECTED]; > santosh.k > Subject: Re :Re: [Sip-implementors] SDP Error Handling -- Unsupported > codec inSDP Answer > > > Hi Alex, > > On the basis of the call flows you have given I feel the controller > behaves more like a b2bua(back to back user agent).The b2bua can also be > used to initiate calls(third party call control). > > In normal proxy or one to one call scenarios the reinvite can be sent > for session negotiation or for a session refresh with session expires > header.But the uas should be supporting that header then the 200 ok will > not have an offer sdp and the call can continue with the already > established sdps.On the other hand if the uas does not support that > header then it will behave like a normal session negotiation. > > But in b2bua when it initiates a call by acting as third party call > controller the initial invites or the reinvites may or maynot have an > sdp(rfc 3725). > > I believe this should be the way it works.Guys what do u think?? > regards, > Ramprakash > > > > > On Tue, 18 Mar 2008 17:25:40 0800 [EMAIL PROTECTED] wrote > Actually, this question is related to the usage of the Re-invite w/o SDP > offer. So far, I have idea about the context of this kind of re-invite, > except, in this forum, Yongxin ever raised such a scenario in which the > re-invite w/o SDP offer is used. > > His thread is > http://www.mail-archive.com/[EMAIL PROTECTED]/msg14825.ht > ml<http://www.mail-archive.com/[EMAIL PROTECTED]/msg14825.html> > Below is the callflow, however I don't know what the service is: > > A Controller B C > |(1) INVITE no SDP | | | > || | | > | |(3) INVITE offer1 | | > | |------------------>| | > | |(4) 200 OK answer1 | | > | || | > |(6) ACK answer1 | | | > || | | > |(9) 200 OK | | | > || | > |(11) 200 offer2 | | > || > |(13) 200 answer2' | > || > |(15) ACK answer2 | | > |------------------>| | > |(16) RTP | > |................| > > > Alex Zhang > ESN: 6-554-8782 > > > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Monday, March 17, 2008 8:34 PM > To: Alex Zhang (GDNTRND) > Cc: [EMAIL PROTECTED]; [email protected] > Subject: Re: [Sip-implementors] SDP Error Handling -- Unsupported codec > inSDP Answer > > > > [EMAIL PROTECTED] wrote: > > Thanks, > > > > So, the UAS can not take for granted that the previous SDP is to be > > used for both ways if it just ignores codec3 without terminating the > session. > > Right? > > Once you get outside the valid behavior specified by the standards you > can take nothing for granted. You are by definition dealing with > behavior. > > Paul > > > Alex Zhang > > ESN: 6-554-8782 > > > > > > -----Original Message----- > > From: Vikram Chhibber [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 17, 2008 4:40 PM > > To: Alex Zhang (GDNTRND) > > Cc: [EMAIL PROTECTED]; [email protected] > > Subject: Re: [Sip-implementors] SDP Error Handling -- Unsupported > > codec in SDP Answer > > > > If the UAS continues the call, the behavior is implementation > specific. > > This could lead to one way media or no media at all. It may happen > > that UAC sending codec-3 which UAS is not able to understand and UAS > > sending previous negotiated codec that UAC may be able to process. > > RFC 3264 specifies how answer should be created and does not > > explicitly mentions about what to do in this scenario. Terminating the > > session is the most logical thing to do in my opinion. > > http://www.veraznetworks.com/ > > /Vikram > > On Mon, Mar 17, 2008 at 1:56 PM, wrote: > >> What will happen if the UAS decide to continue the call? > >> Actually, the UAC may have some errors, such as select a wrong codec > > > >> outside the codec list of the SDP Offer. Will the continuing call > >> cause a mismatch of the stream? > >> > >> Please also give reference about this beahvior? Thanks, > >> > >> > >> Alex Zhang > >> ESN: 6-554-8782 > >> > >> > >> > >> > >> -----Original Message----- > >> From: Madhav Bhamidipati [mailto:[EMAIL PROTECTED] > >> Sent: Monday, March 17, 2008 4:20 PM > >> To: Alex Zhang (GDNTRND) > >> Cc: [email protected] > >> Subject: Re: [Sip-implementors] SDP Error Handling -- Unsupported > >> codec in SDP Answer > >> > >> I wonder if it sends ACK in the first place with an unrelated codec. > >> If UAC sends a kind of > >> 4XX then call continuation is still possible, i.e UAS has still an > >> option to continue the call with old parameters. > >> > >> If it sends ACK then UAS sends BYE with no other option. > >> > >> Madhav > >> > >> On 3/17/08, [EMAIL PROTECTED] wrote: > >> > Hi, > >> > > >> > Can anybody give guideline about the UAS Behavior as below: > >> > > >> > UAC UAS > >> > > >> > | | > >> > |-----Re-invite(w/o SDP offer)--->| > >> > | | > >> > |> > | | > >> > |-------ACK (Codec 3)------------>| > >> > | | > >> > | | > >> > > >> > Will UAS release the call or continue the call with the previous > > SDP? > >> > Thanks, > >> > > >> > Alex > >> > _______________________________________________ > >> > Sip-implementors mailing list > >> > [email protected] > >> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > > >> > >> _______________________________________________ > >> Sip-implementors mailing list > >> [email protected] > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > ICL > <http://adworks.rediff.com/cgi-bin/AdWorks/click.cgi/www.rediff.com/sign > ature-home.htm/[EMAIL PROTECTED]/2069675_2062292/2069751/1?PARTNER=3&OA > S_QUERY=null<http://adworks.rediff.com/cgi-bin/AdWorks/click.cgi/www.rediff.com/signature-home.htm/[EMAIL > PROTECTED]/2069675_2062292/2069751/1?PARTNER=3&OAS_QUERY=null> > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
