Re: [Sip-implementors] Codec negotiation on SIP Referred-by

2017-10-10 Thread Paul Kyzivat 

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 > 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

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

Re: [Sip-implementors] Codec negotiation on SIP Referred-by

2017-10-10 Thread Dale R. Worley 
Ivo Vastert  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
   SBCSIP 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 <--|
  |   ||
  |   |   200 OK   |
  |   |   SDP offer|
  |   |<---|
  |   ||
  |   re-INVITE   ||
  |   SDP offer   ||
  |<--||
  |   ||
  |   200 OK  ||
  |   SDP answer  ||
  |-->||
  |   ||
  |   |  ACK   |
  |   |  SDP answer|
  |   |--->|
  |   ||
  |   ACK ||
  |   no SDP  ||
  |<--|

Re: [Sip-implementors] Codec negotiation on SIP Referred-by

2017-10-10 Thread Ivo Vastert 
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.
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  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
> 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

Re: [Sip-implementors] Codec negotiation on SIP Referred-by

2017-10-10 Thread Paul Kyzivat 

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
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors