I would say 3 makes total sense as the Re-invite is happening after a dialog is complete so not sure why the spec wont allow it. So it would be more or less a mid call change ( in confirmed state ) happening from a callee side which would be the application server trying to bridge the call to the called party skipping the announcement server. 3 should work fine and the origin field has to be changed because now the call needs to be bridged to the called party which is a whole new endpoint supporting different codecs with different connection identifiers etc.
I'd say why not just send the 200OK with the answer to the initial offer in the Invite and then play the annoucement and then bridge using a re-invite. Unless you are trying to save the time charged till the annoucement is played, which a lot of prepaid apps try to do, then this thing gets complicated. I guess in that case, the application server can send the answer in rel-183 and then the moment the call needs to be bridged, send a 200Ok and a re-invite, which is exactly what is shown in (3). M -----Original Message----- From: Darshan Bildikar [mailto:[EMAIL PROTECTED] Sent: Monday, October 02, 2006 11:56 PM To: 'Retesh Chadha'; [EMAIL PROTECTED] Cc: [email protected]; [email protected] Subject: [Sip] RE: [Sip-implementors] Early media query I don't think that even Method 3 and 4 are OK because they will involve a change in the origin line parameter of the SDP and that is not allowed as per the RFC. BTW, what was the rationale behind not allowing the origin line to change? It makes implementing apps like prepaid and CRBT very difficult. Could someone please throw some light on this? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Retesh Chadha Sent: Monday, October 02, 2006 5:46 PM To: [EMAIL PROTECTED] Cc: [email protected]; [email protected] Subject: Re: [Sip-implementors] Early media query Hi Udit Of all the methods you have specified, Method 1 and 2 are wrong as per the RFC which states that the sdp of all the provisional and 2xx response of INVITE should be same if they are present. Both Method 3 and 4 look fine, with method 4 being better because in that case 200 ok for INVITE is only sent when the final negotiation (call media) is done. Hope this helps. -- With Regards Retesh Chadha On 10/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi, > > I want to made an application where we can use early media for playing > initial in-band announcements, and then finally connecting the caller to > actual callee (eg prepaid card application). > > I want to know which is the correct way to support this as per SIP RFC. > > Method 1: > > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) 200 OK with SDP | > |<----------------------------| > | | > | | > |(4) ACK | > |---------------------------->| > | | > > > (2) contains SDP of announcement server > (3) contains SDP of callee > > > Method 2: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > | | > | | > |(5) 200 INVITE with sdp | > |<----------------------------| > | | > | | > |(6) ACK | > |---------------------------->| > | | > | | > | | > | | > > (2) contains SDP of announcement server > (5) contains SDP of callee > > > Method 3: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > |(5) 200 OK | > |<----------------------------| > | | > |(6) ACK | > |---------------------------->| > | | > |(7)Re-INVITE with SDP | > |<----------------------------| > | | > | | > |(8) 200 OK with SDP | > |---------------------------->| > | | > |(9) ACK | > |---------------------------->| > > (2) contains SDP of announcement server > (5) contains no SDP > (7) contains SDP of callee > (8) contains answer of caller for callee offer > > Her, UDATE can also be used instead of Re-invites. > > Method 4: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > |(5) UPDATE (callee offer) | > |<----------------------------| > | | > |(6) 200 UPDATE (answer) | > |---------------------------->| > | | > |(7) 200 INVITE | > |---------------------------->| > | | > |(8) ACK | > |---------------------------->| > > > In this case, when callee answers, UPDATE is sent to caller to negoitate > audio with caller, and then 200 OK is sent for the initial INVITE. > > Regards, > Udit > _______________________________________________ > 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 mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
