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:09:27 +0200

Hi Paul,

Comments inline ([CHH])

>>I have a question about the case if a non-2xx/415 response 
>>is received, or a timeout occurs, for a MSRP message.
>> 
>>Chapter 6.5.3 says:
>> 
>>"8.  If any other response code is received, or if the transaction
>>times out, the endpoint SHOULD assume the session has failed,
>>either tear down the session, or attempt to re-establish the
>>session by sending an updated SDP offer proposing a new
>>connection.  If a new connection is established, the endpoint MAY
>>choose to resend the content on the new connection."
>> 
>>My question is: what information in the updated the MSRP 
>>media description (m= line) should be changed, to indicate 
>>that the connection should be re-established, ie that the the 
>>m= line is not unchanged, and only send eg as part of a 
>>refresh? The SDP session level o= parameter is not enough, 
>>because the SDP may contain multiple media descriptions (m= 
>>line), and one needs to find out which has been updated? 
>>Since the c= line IP address, and m= line port, has no 
>>meaning in MSRP I guess something in the path attribute would 
>>have to be updated, or? If one doesn't want to change the IP 
>>address/port (may not be possible eg due to firewalls), does 
>>a new resource value indicate that the TCP connection should 
>>be re-established?
>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. 

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.

>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?

>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.

Regards,

Christer Holmberg
Ericsson Finland

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Jun 2004 14:43:49 -0400

> [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.

> 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…

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.

> 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 conne…

- 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] 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.

	Paul