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

From: "Achint Aggarwal" <[email-masked]>
Date: Fri, 18 Feb 2011 12:39:15 +0530

Hi,

I think the figure I posted on the forum got distorted during the
posting.

So I am redrawing it here:

Assumptions:

UA2 has authenticated to relay

R2 supports sessmatch draft (draft-ietf-simple-msrp-sessmatch-10)

SBC/ALG anchors MSRP media packets but does not modify/intercept them.
SO they will not modify MSRP SEND packets

SBC does the topology hiding o both sides during SDP negotiation

MSRP transport protocol is TCP

For brevity not all SDP parameters are shown.

Symbols used:

R2          :     URI and port of Relay R2

Sr2         :     Session ID of Relay R2

U1,U2       :     Uri's and 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             m=path:M2,Sr1
(So for UA2, M2 is the offerer)

(SDP Answer)

                               m=path:M1,Sr2
m=path:R2,Sr2,U2,Su2    

(For UA1, M1 is the answerer)

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

        SEND                    (SBC doesn't modify           SEND

      To:M1,Sr2               anything and just            To:M1,Sr2

      Fr:U1,Su1                  sends it R2)               Fr:U1,Su1
(Here R2 matches the session using Sr2 as per the sessmatch draft)

                                                            Issues:

1.    Even post session matching, where will R2 route the packet??

2.    If R2 decides to send it to UA2, what will be there in the "To:"
header??

Need some suggestions and comments.

Regards

Achint Aggarwal

________________________________

From: Achint Aggarwal 
Sent: Friday, February 18, 2011 11:17 AM
To: [email-masked]'
Subject: Issue with SBC/ALG interop with MSRP Relays

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: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 23 Feb 2011 08:32:52 +0000

Hi Achint,

My understanding of this situation as per the sessmatch draft is the
following: you'll need to implement MSRP B2BUA functionality in your
ALG if you want to support relays.

>From section 5.4:

"The sessmatch extension allows the usage of ALGs that do
   not implement MSRP B2BUA functionality in MSRP communications, unless
   TLS with name based authentication is used, and unless MSRP relays
   are used.  In such cases ALGs need to implement MSRP B2BUA
   functionality, to prevent the MSRP communication from failing."

This is mentioned in section 5.4 under the 'TLS' title which could be
a bit misleading, since it also defines what to do about relays.

If the draft is not updated specifically mentioning updates to RFC4976
compliant endpoints I see no other way os proceeding in the case you
mention.

Regards,

--
/Saúl
http://saghul.net | http://sipdoc.net