Yes agreed but arent we assuming that the application server doing the prepaid application is really a B2BUA so the origin field is always the B2BUA but the stream is changed based on where the media is played from or bridged to? Also my bad with the origin field, got mixed with the version field.
M -----Original Message----- From: Darshan Bildikar [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 1:28 AM To: 'Manpreet Singh'; 'Retesh Chadha'; [EMAIL PROTECTED] Cc: [email protected]; [email protected] Subject: RE: [Sip] RE: [Sip-implementors] Early media query Quoting RFC 3264 Section 8 Nearly all aspects of the session can be modified. New streams can be added, existing streams can be deleted, and parameters of existing streams can change. When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP Why I am saying there is a problem with this is because In the first answer you are probably giving the caller the announcement server SDP (i.e. something like o=mediaserver) and then later updating it with the callee SDP (i.e. something like o=calleeside). If you don't have a B2BUA in between that actually changes the origin line of SDP (i.e. to something like o=APPSERVER) then the flows would actually be invalid because of this restriction. The flows that are described are generally used. I am not saying that they must not be used. What I am saying is that the RFC 3264 places a restriction on them in terms of origin line. However, I don't think this restriction is valid, coz if a change the IP is allowed why not a change in origin line? This is what I am trying to get clarified. ________________________________________ From: Manpreet Singh [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 9:56 AM To: Darshan Bildikar; 'Retesh Chadha'; [EMAIL PROTECTED] Cc: [email protected]; [email protected] Subject: RE: [Sip] RE: [Sip-implementors] Early media query Importance: High 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
