Subject: [Simple] Comments on simple-im-sessions-01

From: [email-masked]
Date: Tue, 18 Mar 2003 21:15:31 +0200

- The first problem, which was already brought up in the simple meeting was about the offer/answer exchange and that it is broken. You certainly need another offer answer exchange and not just an answer to an answer. UPDATE, as suggested, would be used, but I wasn't sure of the call flows in this case. Is it:

--> INVITE offer
<-- 18x answer
--> UPDATE offer
<-- 200 (UPDATE) answer
<-- 200 (INV)
--> ACK

or 
--> INVITE offer
<-- 200  answer
--> UPDATE offer
<-- 200 answer

I think the former has the advantage that the session is only established after the media negotiation is complete. Also, have you considered PRACK?

- Section 6.2 says:
"An MSRP transaction consists of exactly one request and one response.
   A response matches a transaction if it share the same TR-ID value,
   and if the T-URI value in the response matches a the URI for the
   endpoint that sent the request"

Why is there a need for check the T-URI in the response. We are matching transactions here and I assume that TR-ID is unique enough.

- "the msrp uri should be hard to guess and MUST not duplicate any uri used in other active sessions hosted". Can this be exchanged for "the msrp uri must be random and unique for every session"?

- In the steps for hosting a session (Inviter and invitee cases), the steps suggest (step 2 in both cases) to listen for a connection from the peer before sending the SDP offer (answer). Why would you start listening on ports that you haven't informed anyone about yet? I think steps 2 should be the last step. i.e. start listening for connections after you send the SDP.

- 6.6: there needs to be a timeout timer for no responses arriving at all. A timer value of 32 seconds maybe. If no response arrives, the session needs to be torn down.

- I don't understand the need for the visitor to send a LEAVE request. Signalling protocol (BYE) is enough for the host to start tearing down the session.

Regards,
Hisham

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Mar 2003 00:33:07 -0500

inline.

[email-masked] wrote:
 > - The first problem, which was already brought up in the simple
 > meeting was about the offer/answer exchange and that it is broken.
 > You certainly need another offer answer exchange and not just an
 > answer to an answer. UPDATE, as suggested, would be used, but I
 > wasn't sure of the call flows in this case.

The intent is that it should work with a single offer/answer exchange. I 
do not think that doing so is a problem. It merely needs a comedia-like 
step where you drop one of two connections if you end up with both 
getting established.

 > - Section 6.2 says: "An MSRP transaction consists of exactly one
 > request and one response. A response matches a transaction if it
 > share the same TR-ID value, and if the T-URI value in the response
 > matches a the URI for the endpoint that sent the request"
 >
 > Why is there a need for check the T-URI in the response. We are
 > matching transactions here and I assume that TR-ID is unique enough.

I can't think of a reason. Ben, did you have something specific in mind?

 > - In the steps for hosting a session (Inviter and invitee cases), the
 > steps suggest (step 2 in both cases) to listen for a connection from
 > the peer before sending the SDP offer (answer). Why would you start
 > listening on ports that you haven't informed anyone about yet? I
 > think steps 2 should be the last step. i.e. start listening for
 > connections after you send the SDP.

Its really the same as regular offer/answer. You need to be prepared to 
receive media the instant the SDP is sent. The sane way to implement 
that is to being listening just before you send it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Ben Campbell <[email-masked]>
Date: 21 Mar 2003 10:06:43 -0800

Thanks for the comments! 

> I think the former has the advantage that the session is only established after the media negotiation is complete. Also, have you considered PRACK?

In your example above, I am not sure why the callee would be sending a
18x class response under normal circumstances, as it is unlikely to know
the caller will want to take back the host role. It _might_ make sense
to say that the callee should do that _if_ it is attempting to assume
the host role from the caller.

However, on further reflection, I am not sure UPDATE is the way to go
here at all. It may make more sense to have each endpoint advertise
whether they are willing to host, or _must_ host, using something like
the direction attributes from COMEDIA. I think Jonathan was trying to
communicate that to me last week, but I was apparently being dense at
the time.

> Why is there a need for check the T-URI in the response. We are matching transactions here and I assume that TR-ID is unique enough.

The TR-ID is unique only in the context of a session. Therefore
determining a transaction match requires both fields. I wrestled with
whether the T-URI should be unique on its own. What do people think?

> - "the msrp uri should be hard to guess and MUST not duplicate any uri used in other active sessions hosted". Can this be exchanged for "the msrp uri must be random and unique for every session"?

That is more clear, thanks!

> - In the steps for hosting a session (Inviter and invitee cases), the steps suggest (step 2 in both cases) to listen for a connection from the peer before sending the SDP offer (answer). Why would…

If you send the offer, then listen, you have a race condition where the
invitee might attempt to connect before you get the listen port setup.
This is analogous to saying that when sending an offer for an RTP
session,  you must be immediately ready to recieve RTP on the port.

> - 6.6: there needs to be a timeout timer for no responses arriving at all. A timer value of 32 seconds maybe. If no response arrives, the session needs to be torn down.
Oops. I thought I mentioned a timeout in this section, but it appears I
did not. I am not entirely sure we need to specify a time period for it.
At most, maybe a default value. I welcome discussion on whether we
should just arbitrarily pick 32 seconds for a default because it is such
a common number in SIP, or if the reasoning that leads to 32 seconds in
SIP is also true here.

> - I don't understand the need for the visitor to send a LEAVE request. Signalling protocol (BYE) is enough for the host to start tearing down the session.

LEAVE was there to allow a visitor to tell a relay it is leaving, even
if the host fails to do so. However, with the discussion about makeing
both bind and visit into soft-state operations, both LEAVE and RELEASE
probably become moot.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Mar 2003 15:50:21 -0500

>  whether the T-URI should be unique on its own. What do people think?

WHy not just make the TR-ID unique in general, rather than within the 
session?

-Jonathan R.