Ivo Vastert <i.vast...@gmail.com> writes:
> What we try to do is the following scenario:
>
> Inbound call from: #gateway1 ==> #SBC1 ==> SIP client (Gateway offers
> G711alaw, G711ulaw and G729) SBC passes codecs as-is.
> Sip client has codec preference (G722, G729, G711alaw, G711ulaw)
> The SIP client accepts this call, (#Leg1, on G729)
>
> Then the SIP client makes a outbound call: SIP client ==> #SBC1 ==>
> #gateway2
> Sip client has still codec preference (G722, G729, G711alaw, G711ulaw).
> #Gateway2 has codec preference (G722, G711alaw, G729).
> #Gateway2 accepts this call on G722.
>
> So now we have the following situation:
> A SIP client with 2 legs, both going to #SBC1, where #Leg1 is on G729 and
> #Leg2 on G722.
>
> The SIP client sends a SIP REFERED-by to #SBC1 to connect the legs to each
> other.
> In this case there is a codec mismatch, but currently our SBC is still
> bridging the calls which results in bad audio because of a codec mismatch.
>
> What should be the behaviour of the SBC / B2BUA in this case?
The basic scenario is the one without the SBC in the middle:
gateway1 ---> SIP client (sets up dialog A)
SIP client ---> gateway2 (sets up dialog B)
Now, the client wants to connect the two legs, so it sends a REFER
within dialog A containing a Refer-To URI with a Replaces parameter.
This causes gateway1 to set up dialog C with gateway2. Since this is a
new dialog, the gateways negotiate codecs from the beginning, so there
is no mismatch.
Introducing an SBC makes things a lot more complicated because there are
a number of ways an SBC could behave in this scenario. Some involve the
SBC "passing through" the REFER in order to avoid including itself in
the new dialog C.
But not looking at those complications, we are in this state:
dialog A1 dialog A2
gateway1 --------------> ------------\
\
V
SBC SIP UA
/
dialog B2 dialog B1 /
gateway2 <-------------- <-----------/
If the SBC wants to continue dialogs A1 (from gateway1 to SBC) and B2
(from SBC to gateway2), then it needs to create a new dialog C to
replace A2 and B1, where both endpoints of dialog C are on the SBC, with
one endpoint being "connected to" A1 and one endpoint being "connected
to" B2. Logically, this is the effect of the UA's REFER arriving at
SBC's end of A2, directing that endpoint connect with SBC's end of B1:
dialog A1
gateway1 --------------> ----\
|
|
SBC | dialog C
|
dialog B2 |
gateway2 <-------------- <----/
Since A1 and B2 have been negotiated with different codecs, SBC has to
do transcoding between the two dialogs, which is computationally
expensive and gives poor audio quality.
The usual solution is to force gateway1 and gateway2 to carry out a
media renegotiation to agree on a common codec, so that SBC can simply
pass media packets through without transcoding.
The usual way to do this is with a "Z-shaped re-INVITE", which is named
after the way the messages are shown in a "railroad diagram". The SBC
forces one leg (gateway2) to generate an SDP offer by sending it a
re-INVITE without SDP. SBC then passes the offer gateway2 generated to
gateway1 in a re-INVITE. Gateway1 generates an answer, which SBC passes
to gateway2 in the ACK.
gateway1 SBC gateway2
| | |
| | re-INVITE |
| | no SDP |
| |------------------->|
| | |
| | 200 OK |
| | SDP offer |
| |<-------------------|
| | |
| re-INVITE | |
| SDP offer | |
|<----------------------| |
| | |
| 200 OK | |
| SDP answer | |
|---------------------->| |
| | |
| | ACK |
| | SDP answer |
| |------------------->|
| | |
| ACK | |
| no SDP | |
|<----------------------| |
| | |
| | |
The result is that gateway1 and gateway2 have aggreed on common
codec(s), so SBC can just pass media packets between them without
alteration. (If gateway1 and gateway2 can send directly to each other,
SBC can pass the media address of each gateway to the other, and then
SBC doesn't even have to handle the media packets.)
This does require that at least one of the gateways is willing to change
the codec it is using in the dialog. Some gateways try to "pin" what
codec is used for the duration of a call. That will lead to one or both
of the re-INVITEs being rejected. In that case, SBC could try replacing
the leg with a new dialog, by sending an INVITE for a new dialog
containing a Replaces header that identifies the old dialog.
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
