The problem is that not every error scenario is covered by SIP specs. You can make a "wise" guess but it is just a guess. The problem is your guess might not be the same as the guesses of others.
Anyway, BYEing the call with a useful error message (in the device's log and if possible in a SIP header) is as good a way as any. Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 20 March 2008 13:25 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip-implementors] Re :Re: SDP Error Handling --Unsupportedcodec inSDP Answer :). I think this is a kind of error handling scenario. What I want to discuss is actually hitting the usage of the "re-invite without SDP offer". I only find that the 3rd party call control service has the usage of such scenario. If the controller does not send the ACK with correct codec value to the UA2 as SDP answer to the 200OK(re-invite) w/ SDP offer, how does UA2 react properly? Should UA2 choose to continue the call or notify the controller by a BYE message that the error occurs and then release the call? Alex Zhang ESN: 6-554-8782 -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 9:11 PM To: Alex Zhang (GDNTRND) Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] Subject: Re: Re :Re: [Sip-implementors] SDP Error Handling -- Unsupportedcodec inSDP Answer I've now gotten a little lost in where this is going. Exactly what do you want to know? The original scenario you gave was invalid. Do you want to know how to act when interacting with a device that is doing invalid things? Or are you looking for permission to do invalid things. IMO you may do as you wish in response to invalid behavior. But the main thing you should probably do is complain to the manufacturer of the device that is behaving incorrectly - get them to fix it. Paul [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 > 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/si > gnature-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
