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/sign ature-home.htm/[EMAIL PROTECTED]/2069675_2062292/2069751/1?PARTNER=3&OA S_QUERY=null> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
