Hi Dale! > 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.
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 ;-) -- Hendrik Scholz <[EMAIL PROTECTED]> _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
