Re: [Sip]From sip-bounces at ietf.org Mon Aug 25 06:01:20 2008

[Paul Kyzivat <pkyzivat at cisco.com>]

Dean Willis wrote:
> On Aug 24, 2008, at 3:52 PM, Christer Holmberg wrote:
> 
>> Probably the easiest to implement also. Because, if you would use  
>> separate SIP sessions, you would need to somehow "transfer" the ICE/ 
>> SRTP/resource reservation state between them.
>>
>> ...unless you want to perform separate ICE/SRTP/resource reservation  
>> on the early- and the full dialog sessions, which would be really bad.
>>
> 
> Good point.
> 
> 
> 
>>>> The issue with that solution is of course that a forking proxy, as
>>>> currently defined, would terminate all other legs once the first 200
>>>> OK (establishing the early media path of the session) arrives.
>>> One could of course change that behavior and have the forking proxy
>>> return ALL responses.
>> They do currently forward all 200 OK responses, but there will of  
>> course only be multiple 200 OK responses if they were sent before  
>> the CANCEL sent by the forking proxy arrived.
> 
> Right. I meant that the forking proxy would have to not prune the  
> forks, and the UA might have to deal with multiple concurrent media  
> sessions as a result.

There is the Request-Disposition header defined in 3841. 
(Request-Disposition:no-cancel). If anybody actually implemented it.

	Paul
_______________________________________________
Sip mailing list  https://www.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


edia as an endpoint application
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org



Dean Willis wrote:
> On Aug 24, 2008, at 3:52 PM, Christer Holmberg wrote:
> 
>> Probably the easiest to implement also. Because, if you would use  
>> separate SIP sessions, you would need to somehow "transfer" the ICE/ 
>> SRTP/resource reservation state between them.
>>
>> ...unless you want to perform separate ICE/SRTP/resource reservation  
>> on the early- and the full dialog sessions, which would be really bad.
>>
> 
> Good point.
> 
> 
> 
>>>> The issue with that solution is of course that a forking proxy, as
>>>> currently defined, would terminate all other legs once the first 200
>>>> OK (establishing the early media path of the session) arrives.
>>> One could of course change that behavior and have the forking proxy
>>> return ALL responses.
>> They do currently forward all 200 OK responses, but there will of  
>> course only be multiple 200 OK responses if they were sent before  
>> the CANCEL sent by the forking proxy arrived.
> 
> Right. I meant that the forking proxy would have to not prune the  
> forks, and the UA might have to deal with multiple concurrent media  
> sessions as a result.

There is the Request-Disposition header defined in 3841. 
(Request-Disposition:no-cancel). If anybody actually implemented it.

	Paul
_______________________________________________
Sip mailing list  https://www.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