Hi Ivo,
On 10/10/17 5:26 PM, Ivo Vastert wrote:
Hi Paul,
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.
I guess you mean it sends a REFER request addressed to gateway1, with a
Refer-To URI referencing gateway2. Do I have that right? That will go
through SBC1.
Now, does the SBC intercept this and handle it via 3pcc? or does it
allow the REFER to continue to the gateway?
The *natural* thing to do is let gateway1 handle it. In that case, the
gateway will generate a new INVITE. It should load the offer up with
whatever codecs it has - presumably the same as before (G711alaw,
G711ulaw and G729). When that reaches gateway2 it will presumably choose
G711alaw.
If the SBC attempts to instead handle this via 3pcc, and wants to have a
chance to make this work, then it should do so by sending an offerless
re-invite to gateway1. Then gateway1 should respond as above. This can
then be sent as an offer to gateway2 and things should work out as in
the natural case.
If the SBC attempts to do 3pcc but tries to construct an offer for the
re-invite then it needs to be careful or it will mess things up. This is
*hard*.
Thanks,
Paul
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?
Br,
Ivo
On Tue, Oct 10, 2017 at 8:37 PM, Paul Kyzivat <pkyzi...@alum.mit.edu
<mailto:pkyzi...@alum.mit.edu>> wrote:
On 10/10/17 12:33 PM, Ivo Vastert wrote:
Hi,
I have a question regarding possible codec re-negotiation in a
Referred-by
scenario.
We have the following situation:
A UA which has 2 legs open to a SBC / B2BUA.
1 Leg is on G729 and 1 Leg on G722.
The UA is sending a Referred by towards the SBC to bridge the 2
calls.
What should happen with the codec negotiation in this case since
there is a
mismatch?
Can you provide more detail on what is going on here? I can't follow
from the above description. In general, when sending an offer you
are well advised to offer all the codecs you are able to support, to
maximize the possibility of finding an optimal choice for both ends.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
<https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
