Subject: [Simple] Issue with SBC/ALG interop with MSRP Relays

From: "Achint Aggarwal" <[email-masked]>
Date: Fri, 18 Feb 2011 11:16:49 +0530

Hi,

I am facing an issue while trying to implement an MSRP solution
involving SBC and MSRP Relays.

Following is the call scenario:

                             SBC/ALG Interop with MSRP Relays

Assumptions:

1.       UA2 has authenticated to relay R2.

2.       R2 supports the sessmatch draft
(draft-ietf-simple-msrp-sessmatch-10)

3.       SBC/ALG anchors MSRP media packets but does not
intercept/modify them. So MSRP SEND packets will not be modified by
SBC/ALG. 

4.       SBC does the topology hiding on both sides during SDP
negotiation.

5.       MSRP transport protocol is TCP.

6.       For brevity not all the sdp parameters are shown.

Symbols used:

R2                           :               URI & port of Relay R2

Sr1,Sr2                   :               Session ID of relay R2

U1,U2                    :               Uri's & Ports of UA1,UA2

Su1,Su2                 :               Session ID's of UA1, UA2

M1,M2                  :               Uri's &  ports of SBC/ALG

Call flow:

 UA1                                                              SBC
/ALG                                                       R2
UA2     

      (SDP Offer)

      --m=path: U1:Su1                                              

(SDP modified offer)                     

m=path: M2:Su1

(SDP answer)

m=path: R2:Sr2, U2:Su2

                                                (SDP modified answer)

m=path: M1:Sr2

 

 ============================== Session Established
==================================

 SEND

     To:  M1:Sr2

      Fr: U1:Su1                      

                                                (SBC/ALG routes the
packet further without modifying it)

(Sess matches

To: M1:Sr2       due to Sr2 as per draft)      

Fr: U1:Su1

Issues:    

1. Confusion over further routing (Even if session is matched how R2
will know where to further route this packet??)

2. Even if R2 routes SEND to UA2 then what will be there in "To-path:"
header just before R2 forwards SEND???

 

 

 

 

 

Need some suggestions and comments.

Regards

Achint Aggarwal

---

From: Ben Campbell <[email-masked]>
Date: Fri, 18 Feb 2011 00:19:06 -0600

(As individual)

Hi,

I think you've found 2 problems:

1) I don't think draft-ietf-simple-msrp-sessmatch contemplated that the SBC would do topology hiding in the SDP path attribute. That simply isn't going to work if a relay is involved, since the route past the relay is lost.

2) The sessmatch draft does not, if I recall correctly, extend RFC 4976--so I don't expect that relays in general will implement it. I guess there might be an argument that 4976 inherits the session matching rules from RFC 4975, which is extended by sessmatch. But I don't think the authors contemplated that sessmatch would be implemented by relays. (I'm sure they will correct me if I am mistaken on that point.)

In any case, I think you've highlighted why an SBC that modified the SDP path attribute but does not modify the To-Path in a SEND request is not interoperable with RFC 4976 relays in  the precise case where such interoperability would be most important.

Christer, do you have any thoughts on this?

Thanks!

Ben.

On Feb 17, 2011, at 11:46 PM, Achint Aggarwal wrote:

> Hi,
> I am facing an issue while trying to implement an MSRP solution involving SBC and MSRP Relays.
> Following is the call scenario

[...]