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 | | | |<------------------| | | |(2) 200 offer1 | | | |------------------>| | | | |(3) INVITE offer1 | | | |------------------>| | | |(4) 200 OK answer1 | | | |<------------------| | | |(5) ACK | | | |------------------>| | |(6) ACK answer1 | | | |<------------------| | | |(7) RTP | | | |.......................................| | |(8) BYE | | | |------------------>| | | |(9) 200 OK | | | |<------------------| | | |(10) re-INV no SDP | | |------------------>| | |(11) 200 offer2 | | |<------------------| | |(12) INV offer2' | | |----------------------------------->| |(13) 200 answer2' | |<-----------------------------------| |(14) ACK | |----------------------------------->| |(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 undefined 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, <[EMAIL PROTECTED]> 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] <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > Can anybody give guideline about the UAS Behavior as below: >> > >> > UAC UAS >> > <========== Session Establised=========> >> > | | >> > |-----Re-invite(w/o SDP offer)--->| >> > | | >> > |<----200 OK(Codec1, Codec2)------| >> > | | >> > |-------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
