Quoting response from Retesh Chadha:
>>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.
Retesh I think you are quoting RFC3261 section 13.2.1? Please confirm. I could
not find the exact statement in the RFC.
o If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
Because method 3 and 4 requires an origin field change which conflicts with
RFC3264. See Darshan's comments.
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: 2006?10?9? 20:47
To: Xia, Zhi Feng (Bruce)
Cc: Darshan Bildikar; [email protected]; [email protected]; Retesh
Chadha
Subject: Re: [Sip] Re: [Sip-implementors] Early media query
The Replaces approach is a possibility. But please explain why you think
all the possibilities are invalid.
Paul
Xia, Zhi Feng (Bruce) wrote:
> Given the restrictions in RFC, all four methods seem invalid.
>
> Before we can change the restrictions in the RFC, it looks to me using
> "replaces" is a better approach...
>
> How about this flow:
>
>> Caller Callee
>> | |
>> | |
>> |(1) INVITE with offer |
>> |----------------------------> |
>> | |
>> | |
>> |(2) 183 with answer 1 |
>> |<-------------------------------|
>> | |
>> | |
>> |(3) PRACK |
>> |----------------------------> |
>> | |
>> | |
>> |(4) 200 PRACK |
>> |<------------------------------|
>> |(5) 200 OK |
>> |<---------------------------- |
>> | |
>> |(6) ACK |
>> |---------------------------->|
>> | |
>> |(7)Re-INVITE(replaces with new call id)
>> |<----------------------------|
>> | NOTIFY |
> |----------------------------->
> |BYE(the original call id)
> |----------------------------->
>> | |
>> |(8) 200 OK with SDP |
>> |---------------------------->|
>> | |
>> |(9) ACK |
>> |---------------------------->|
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: 2006?10?5? 22:52
> To: Darshan Bildikar
> Cc: [email protected]; [email protected]; 'Retesh Chadha'
> Subject: [Sip] Re: [Sip-implementors] Early media query
>
>
>
>
> Darshan Bildikar wrote:
>> 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.
>
> Which RFC?
>
> I suport Crister's response.
>
> Paul
>
>> 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.
>
> _______________________________________________
> 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
