Subject: [BLISS] draft-worthy? call forking handling

From: Hendrik Scholz <[email-masked]>
Date: Wed, 12 Mar 2008 20:43:50 +0100

Hi!

In both parallel and sequential call forking scenarios we've seen
problems with signalling and media handling.
Problems include selection/usage of the wrong route set to send
replies as well media mixing issues (two early media streams).

B2BUAs in form of SBCs make things even worse but at the same time
could be used to normalize traffic for a UAC.

My intention is to outline how forked calls should be handled with
regards to both signalling and media.

This doesn't really match the WG charter but would serve as
a basis for (some of) the call forwarding scenarios.
A forwarded call (CFNA) might have provided media already which
would make the call a sequentially 'forked' call.

Does this make sense to you?

Best Regards,
  Hendrik

P.S. I'm here in Philly if you are interested in discussing the content
      face to face.

-- 
Hendrik Scholz <[email-masked]>
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: [email-masked]
Date: Fri, 14 Mar 2008 16:22:26 -0500

From: Hendrik Scholz <[email-masked]>

Are there unanswered questions about how forked calls should be
handled?  It is true that there are many deficient implementations,
but I do not know of any disputes regarding what is correct behavior.

Dale

---

From: Hendrik Scholz <[email-masked]>
Date: Wed, 26 Mar 2008 14:54:32 +0100

Hi Dale!

> but I do not know of any disputes regarding what is correct behavior.

The problems that we've seen in the past is outline below.
It all boils down to multiple early media streams handling.
In the outlined scenario a SIP proxy behind an SBC forks
a call generating multiple early media streams.

call setup)

  UAC          SBC       SIP Proxy      UAS X       UAS Y
 1 |---INVITE-->|            |            |           |
 2 |            |---INVITE-->|            |           |
 3 |            |            |---INVITE-->|           |
 4 |            |            |---------------INVITE-->|
 5 |            |            |<--183/SDP--|           |
 6 |            |<=================RTP====|           |
 7 |            |<--183/SDP--|            |           |
 8 |<====RTP====|            |            |           |
 9 |<--183/SDP--|            |            |           |
10 |            |            |<--------------183/SDP--|
11 |            |<==============================RTP===|
12 |            |<--183/SDP--|            |           |

scenario 1)

  UAC          SBC       SIP Proxy      UAS X       UAS Y
13 |            |            |<--200/SDP--|           |
14 |            |<--200/SDP--|            |           |
15 |<--200/SDP--|            |            |           |
16 |            |---CANCEL-->|            |           |
17 |            |            |---------------CANCEL-->|
18 |====RTP====>|            |            |           |
19 |            |=================RTP====>|           |

scenario 2)

  UAC          SBC       SIP Proxy      UAS X       UAS Y
13 |            |            |<--200/SDP--------------|
14 |            |<--200/SDP--|            |           |
15 |            |<====RTP=============================|
16 |<--200/SDP--|            |            |           |
17 |<====RTP====|            |            |           |
18 |            |---CANCEL-->|            |           |
19 |            |            |---CANCEL-->|           |
20 |====RTP====>|            |            |           |
21 |            |=============================RTP====>|

In the generic call setup part the SBC forwards the first 183 with
SDP it receives to the UAC.
If the same UAS (UAS X) also fully establishes the session there
is no major issue.
But in the second case (scenario 2; UAS Y sends the 200 OK w/ SDP)
there are interworking things that need to be clarified.
UAS Y may use a different codec than the one announced by UAS X
in the 183. How should this be resolved?

From the feedback that we internally gathered during an SBC
evaluation we figured that most vendors never thought of this case.
Some forward both early media streams to the UAC and things get
ugly.

Maybe I'm not aware of the document that defines the expected
behaviour so throw RFC numbers and draft names at me if applicable ;)

As a solution I came up with an SBC that uses transcoding as
a remedy to the issue above[0].
In a nutshell the SBC doesn't have to do any transcoding in
scenario 1). If scenario 2) applies the SBC _may_ have to
deal with transcoding. In that case it receives media from UAS Y,
transcodes it to the codec as offered by UAS X and sends it
to the UAC. At a reasonable point soon after the 200 OK
the SBC tries to renegotiate the codec with either the UAS Y or
UAC. In general I'd prefer the side that has more known working
SIP devices (i.e. your internal Class 5 switch).

Best Regards,
 Hendrik

0: I believe I will hate myself for mentioning SBC, transcoding and
remedy in one sentence some time really soon ;-)