Subject: RE: [Simple] MSRP: updated offer on transaction timeout or non-2x x/415 respons e

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 7 Jun 2004 20:54:52 +0200

Hi Paul,

>>>Assuming you don't have reason to change something else, it 
>>>would be sufficient to simply change the 'resource' portion of the msrp url.
>> 
>>[CHH] I guess it would be good to clarify that in the draft. 
> 
>Yeah, I guess it would, though it is implicit once you 
>realize you have to change something. If you prefer you may change the port, or some 
>other part of the address.
>
>Hmm. I wonder if it would be sufficient to change something 
>in the offer  that is ignored, like the port in the m-line or the address in the 
>c-line? I suppose that wouldn't be ideal, because it would require 
>paying attention to stuff that is ignored.

[CHH] That would solve the what-if-there-is-no-resource-portion problem.

>>Of course, there is also the case where there is no 
>>resource portion used (since it's optional), so I guess in 
>>that case it would have to be mandatory to include the 
>>resource portion in the updated offer.
>This falls into the category of "if it hurts, don't do it". 
>Omitting the resource part only works if you only have one resource.

[CHH] It depends on how you define "resource". Your one one only resource may be a single TCP socket, or the ability to handle one MSRP session at a time, but that would still be true even if you send a new offer.

>>>Also, does the node really need to send an updated SDP in 
>>>the first place, if the IP parameters don't change? Why not 
>>>just trying to re-establish the TCP connection?
>>>
>>>1) because permitting this would require that a tcp listener 
>>>always be active just in case this should happen. This could be a 
>>>burden for some nodes.
>> 
>>[CHH] That's a good point.
>> 
>>However, doesn't a SIP node have to have the listener 
>>active always anyway, for incoming SIP requests (if TCP is 
>>used), since there is no requirement (it may be recommended, 
>>though) to keep a connection open for the whole session?
> 
>- the node where the media is terminated may be different 
>from the place where the sip signaling is terminated
> 
>- I really don't think you want to use the same port to 
>listen for sip and MSRP connections. How would you know which protocol is to 
>be used on the connection? While you could wait for the first message, 
>that seems like a bad idea.

[CHH] I agree. I didn't think of using the same port, but of course it's heavier the more ports you have to listen to.

>>>2) because an attempt to establish a connection when one is already 
>>>active is interpretted as an attack.
>> 
>>[CHH] The offerer would tear down the old connection before 
>>establishing the new one, in the same way it would do when 
>>receiving an answer to an updated offer.
>There are at obscure race conditions and failure modes here.

Ok.

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple