Subject: Re: [Simple] Sessmatch - an alternative approach

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2011 09:04:16 +0200

Hi, 

>Great! I really like that we have this as a must, it means we 
>have no breakage when users behind an ALG and users not 
>behind an ALG interact with each other :-)

Yes.

It is also good because it will allow 4975 UAs to communicate with each other when there is an ALG in the path.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2011 11:02:28 +0200

Actually, when reading RFC 4975 it is a little unclear what address will be in the SDP c/m-line when a UA uses a relay.

There is text saying:

      "MSRP devices do not use the c-line address field, or the m-line
      port and format list fields to determine where to connect.
      Rather, they use the attributes defined in this specification.
      The connection information is copied to the c-line and m-line for
      purposes of backwards compatibility with conventional SDP usages.
      While MSRP could theoretically carry any media-type, "message" is
      appropriate."

In my opinion "connection information" refers to the address where a connection is to be established, and that is the address of the relay.

IF we can assume that the c/m-line contains the relay address, then B2BUA mode will only be used when the UA behind the relay is "active".

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 1. kesäkuuta 2011 9:59
> To: Ben Campbell
> Cc: [email-masked]
> Subject: Re: [Simple] Sessmatch - an alternative approach
> 
> 
> Hi Ben, 
> 
> >How does this work when the peer is behind an MSRP Relay? 
> >Keep in mind that, in this case, the c/m lines will refer to the 
> >endpoint itself, not to the relay.
> 
> You are probably right. If the 4975 UA is behind a relay, the 
> sessmatch UA needs to trigger a fallback to 4975 (in a 
> similar way as when the 4975 UA is "active"). The sessmatch 
> UA can do if it detects that the remote SDP contains multiple 
> a=path attributes, indicating that there is relay(s) in the path.
> 
> The reason is that the 4975 UA has inserted its own address 
> in the SDP c-line (at least I can't find text in RFC 4976 
> which says otherwise), so the ALG would try to connect to the 
> 4975 UA rather than the relay.
> 
> Good point!
> 
> Regards,
> 
> Christer
> 
> 
> 
> > On May 30, 2011, at 2:40 PM, Christer Holmberg wrote:
> > 
> > > Hi,
> > > 
> > > Based on the issues that have been raised on sessmatch, I
> > would like to present a modified version, that solves some of the 
> > raised issues related to security, backward compability, 
> usage of the 
> > Require header filed, and specifying of ALG behavior. It has the 
> > following advantages over the current sessmatch mechanism:
> > > 
> > > 1. Except for one case, that still requires MSRP B2BUA, it
> > works with
> > > "legacy" SIP-ALGs (that only modify the SDP c/m line, but not the
> > > a=path) - EVEN when a SIP-ALG is communicating with a RFC 4975 UA;
> > > 
> > > 2. It works with name based authentication;
> > > 
> > > 3. It works when a 4975 UA is behind a relay;
> > > 
> > > 4. It works without a need for the offerer, or for the
> > SIP-ALG, to use
> > > the Require header field; and
> > > 
> > > 5. It atually REMOVES the need to update the session matching 
> > > procedure in the first place :)
> > > 
> > > 
> > > The idea is based on the very original sessmatch proposal,
> > where a sessmatch UA sends the TCP SYN for the MSRP 
> connection based 
> > on the SDP c/m-line, rather than the a=path.
> > > 
> > > BUT, the sessmatch UA still inserts the a=path MSRP URI
> > into the MSRP message, use it for name based 
> authentication, and use 
> > if for session matching - all according to existing RFC 4975 
> > procedures.
> > > 
> > > 
> > > Let's look at how it works.
> > > 
> > > 
> > > Peer-to-peer (no SIP-ALG)
> > > -----------------------------
> > > 
> > > As in the current sessmatch proposal, there is still full
> > backward compability. As the a=path and SDP c/m-line values will be 
> > identical, it doesn't matter which the sessmatch UA uses 
> for sending 
> > the TCP SYN.
> > > 
> > > (In fact, we could even specify that the sessmatch UA uses
> > the a=path
> > > in case it is identical to the SDP c/m-line, and everything
> > would be
> > > identical to RFC 4975.)
> > > 
> > > 
> > > SIP-ALG in the path
> > > ---------------------
> > > 
> > > 
> > > 1. A sessmatch UA sends a request that offers MSRP, and
> > includes a sessmatch support indication (option-tag, SDP 
> attribute, or 
> > whatever we choose).
> > > 
> > > 2. The SIP-ALG modifies the SDP c/m-line of the offer, and
> > the corresponding answer, in order to anchor the MSRP media. 
> > The a=path is NOT modified.
> > > 
> > > 3. The sessmatch UA receives the answer from the remote UA.
> > > 
> > > 4a. If the remote UA supports sessmatch, everthing is fine. 
> > Whoever is "active" sends the TCP SYN according to the SDP c/m line 
> > (which points to the ALG).
> > > 
> > > 4b. If the remote UA does NOT support sessmatch, BUT is
> > "passive" (default if it does not support MSRP ACM), everything is 
> > fine. The sessmatch sends the TCP SYN according to the SDP c/m line 
> > (which points to the ALG).
> > > 
> > > 4c. If the remote UA does NOT support sessmatch, AND is
> > "active", things will NOT work (unless SIP-ALG bypass is 
> allowed), as 
> > the remote UA will try to send the TCP SYN according to 
> a=path (which 
> > points to the sessmatch UA, rather than to the ALG).
> > > 
> > > 5. In case of 4c, the sessmatch UA does a "fallback" to
> > 4975, by sending a new offer where it does NOT include a sessmatch 
> > support indication. The SIP-ALG, in order to support MSRP, will now 
> > have to enable MSRP B2BUA functionality.
> > > 
> > > 
> > > It works the same in the other direction, where the 4975 UA
> > sends the offer. If the 4975 UA becomes "active", the sessmatch UA 
> > will have to send an offer without sessmatch indication.
> > > 
> > > 
> > > Regards,
> > > 
> > > Christer
> > > _______________________________________________
> > > Simple mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/simple
> > 
> > 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 1 Jun 2011 08:17:55 -0500

On Jun 1, 2011, at 1:58 AM, Christer Holmberg wrote:

>> Keep in mind that, in this case, the c/m lines will refer to 
>> the endpoint itself, not to the relay.
> 
> You are probably right. If the 4975 UA is behind a relay, the sessmatch UA needs to trigger a fallback to 4975 (in a similar way as when the 4975 UA is "active"). The sessmatch UA can do if it detects that the remote SDP contains multiple a=path attributes, indicating that there is relay(s) in the path.
> 
> The reason is that the 4975 UA has inserted its own address in the SDP c-line (at least I can't find text in RFC 4976 which says otherwise), so the ALG would try to connect to the 4975 UA rather than the relay.

I looked for that too, and can't find anything that tells an endpoint to use the relay address/port in c/m.

>> would like to present a modified version, that solves some of 
>> the raised issues related to security, backward compability, 
>> usage of the Require header filed, and specifying of ALG 
>> behavior. It has the following advantages over the current 
>> sessmatch mechanism:
>>> 
>> connection based on the SDP c/m-line, rather than the a=path.
>>> 
>> into the MSRP message, use it for name based authentication, 
>> and use if for session matching - all according to existing 
>> RFC 4975 procedures.
>>> 
>>> 
>> backward compability. As the a=path and SDP c/m-line values 
>> will be identical, it doesn't matter which the sessmatch UA 
>> uses for sending the TCP SYN. 
>>> 
>> attribute, or whatever we choose).
>>> 
>> Whoever is "active" sends the TCP SYN according to the SDP 
>> c/m line (which points to the ALG).
>>> 
>> "passive" (default if it does not support MSRP ACM), 
>> everything is fine. The sessmatch sends the TCP SYN according 
>> to the SDP c/m line (which points to the ALG).
>>> 
>> allowed), as the remote UA will try to send the TCP SYN 
>> according to a=path (which points to the sessmatch UA, rather 
>> than to the ALG).
>>> 
>> 4975, by sending a new offer where it does NOT include a 
>> sessmatch support indication. The SIP-ALG, in order to 
>> support MSRP, will now have to enable MSRP B2BUA functionality.
>>> 
>>> 
>> sends the offer. If the 4975 UA becomes "active", the 
>> sessmatch UA will have to send an offer without sessmatch indication.
>>> 
>>> 
>>> Regards,
>>> 
>>> Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 1 Jun 2011 08:24:52 -0500

From 4975, section 8.1:

>    The network type and address type fields are used as normal for SDP.
>    The connection address field MUST be set to the IP address or fully
>    qualified domain name from the MSRP URI identifying the endpoint in
>    its path attribute.
> 

and

>    The port field value MUST match the port value used in the endpoint's
>    MSRP URI in the path attribute...

I think that's pretty clear that it talks about the endpoint's MSRP URI, since it uses the words "endpoint's MSRP URI".

You might find implementers of 4976 deciding on their own to put the first relay in a chain in the m/c lines. But since there's no guidance to do that in 4976, we can't depend on it.

I'd be curious what any deployed implementations of 4976 do.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2011 15:26:59 +0200

Hi,

>You might find implementers of 4976 deciding on their own to put the first relay in a chain in the m/c lines. But since there's no guidance to do that in 4976, we can't depend on it.

You're probably right. I also noted that the examples in section 11 of 4976 use the UA adderss in the c/m line.

However, we CAN specify that a sessmatch UA behind a relay must insert the address of the relay in the c/m line, and then there won't be a need for B2BUA mode, at least not because of the sessmatch UA.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 1 Jun 2011 15:32:26 +0200

> I'd be curious what any deployed implementations of 4976 do.

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.6:53801;rport;branch=z9hG4bKPjKLKpmKrBKMsrbqm8N5K9YSGr9AyluN4b
Max-Forwards: 70
From: "Adrian Georgescu" <sip:[email-masked]>;tag=aNgZOMfUHAWrZEk8O4V.UNTA7DhMjQBz
To: <sip:[email-masked]>
Contact: <sip:[email-masked]:53801>
Call-ID: URMwCeJgVDb88LWQnNTKryn1-Lu2LeRC
CSeq: 24276 INVITE
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
Supported: 100rel, norefersub
User-Agent: Blink Pro 1.1.0 (MacOSX)
Content-Type: application/sdp
Content-Length:   411

v=0
o=- 3515923660 3515923660 IN IP4 192.168.1.6
s=Blink Pro 1.1.0 (MacOSX)
c=IN IP4 192.168.1.6
t=0 0
m=message 61328 TCP/TLS/MSRP *
a=path:msrps://node03.dns-hosting.info:2855/l/KNsOeOcGJ/5ZbY6lVRPDEzMDY5MzQ4NjAuNDQyOjgwLjEwMS45Ni4yMA==;tcp msrps://192.168.1.6:61328/553d54d23aed8350fe25;tcp
a=accept-types:message/cpim text/* application/im-iscomposing+xml
a=accept-wrapped-types:*

---

From: Ben Campbell <[email-masked]>
Date: Wed, 1 Jun 2011 08:36:53 -0500

> a=accept-types:message/cpim text/* application/im-iscomposing+xml

Thanks Adrian!

That has the endpoint address and port in c and m. I think that answers the question.