Subject: [Simple] Sessmatch products

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2011 11:46:52 +0200

Hi,

There has been comments about the existence of sessmatch products, so let me give some information from my own company.

The Ericsson's carrier class SBC currently supports running in either sessmatch mode or TCP/MSRP B2BUA mode, and we currently see no problem in implementing fallback. 

In sessmatch mode the troughput for MSRP packets is line-interface wirespeed, while in MSRP B2BUA mode the maximum throughput for MSRP packets is much lower.

One application we are using MSRP for is to transfer video clips between user endpoints, and we would like to have the option of not having to use B2BUA mode if it can be avoided. 

So, the main issue (at least not from our perspective) is not the code it takes to implement TCP/MSRP B2BUA functionaltiy, but the performance impacts when one has to use it.

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 26 May 2011 11:53:28 +0200

Hi,

> There has been comments about the existence of sessmatch products, so let me give some information from my own company.

Cool, real stuff :-)

> So, the main issue (at least not from our perspective) is not the code it takes to implement TCP/MSRP B2BUA functionaltiy, but the performance impacts when one has to use it.

I understand. What about this: since your endpoints support sessmatch, the cheapest approach would be used by your ALG and the performance would be just fine. And if another endpoint that does not support sessmatch connects to your ALG the B2BUA mode would be used.

Would that be reasonable for vendors? They can implement sessmatch on the endpoints but keeping the B2BUA mode for those who don't.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 26 May 2011 12:31:20 +0200

> So, the main issue (at least not from our perspective) is not the code it takes to implement TCP/MSRP B2BUA functionaltiy, but the performance impacts when one has to use it.

I wonder whether small manufactures of routers (those which include
painful SIP-ALG enabled by default) will be also capable of building
such fallback mechanism (MSRP B2BUA).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2011 12:39:18 +0200

Hi,

>>So, the main issue (at least not from our perspective) is 
>>not the code it takes to implement TCP/MSRP B2BUA 
>>functionaltiy, but the performance impacts when one has to use it.
> 
>I wonder whether small manufactures of routers (those which 
>include painful SIP-ALG enabled by default) will be also 
>capable of building such fallback mechanism (MSRP B2BUA).

I don't know. But, they are maybe not even going to implement sessmatch, so there is nothing we can do about it.

The only thing WE can do is to describe how things need to be done in order for things to work, and then let the market and competition take care of the rest.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2011 13:42:34 +0200

Hi, 

>>There has been comments about the existence of sessmatch 
>>products, so let me give some information from my own company.
> 
>Cool, real stuff :-)

My task in standardization is to work on stuff that actually is intented to be implemented :)

>>The Ericsson's carrier class SBC currently supports running 
>>in either sessmatch mode or TCP/MSRP B2BUA mode, and we 
>>currently see no problem in implementing fallback. 
>> 
>>In sessmatch mode the troughput for MSRP packets is 
>>line-interface wirespeed, while in MSRP B2BUA mode the 
>>maximum throughput for MSRP packets is much lower.
>> 
>>One application we are using MSRP for is to transfer video 
>>clips between user endpoints, and we would like to have the 
>>option of not having to use B2BUA mode if it can be avoided. 
>> 
>I understand. What about this: since your endpoints support 
>sessmatch, the cheapest approach would be used by your ALG 
>and the performance would be just fine. And if another 
>endpoint that does not support sessmatch connects to your ALG 
>the B2BUA mode would be used.

Correct. As I said, we see no problem in doing fallback from sessmatch to B2BUA.

Of course, due to the need to more resources, a fallback call could be rejected due to lack of resources. But, that is true for any type of call, and any type of media. Even a sessmatch call could be rejected if there are not enough resources to handle it.

>Would that be reasonable for vendors? They can implement 
>sessmatch on the endpoints but keeping the B2BUA mode for 
>those who don't.

I can only speak for my own company :)

Regards,

Christer