[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Re: [Sip-implementors] Early media query
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:pkyzivat at cisco.com]
Sent: 2006?10?9? 20:47
To: Xia, Zhi Feng (Bruce)
Cc: Darshan Bildikar; sip at ietf.org; sip-implementors at cs.columbia.edu; 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:pkyzivat at cisco.com]
> Sent: 2006?10?5? 22:52
> To: Darshan Bildikar
> Cc: sip at ietf.org; sip-implementors at cs.columbia.edu; '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: sip-implementors-bounces at cs.columbia.edu
>> [mailto:sip-implementors-bounces at cs.columbia.edu] On Behalf Of Retesh Chadha
>> Sent: Monday, October 02, 2006 5:46 PM
>> To: Udit_Goyal at 3com.com
>> Cc: sip at ietf.org; sip-implementors at cs.columbia.edu
>> 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip