Author Topic: iLBC negotiation  (Read 3950 times)

looserouting

  • Newbie
  • *
  • Posts: 23
    • View Profile
iLBC negotiation
« on: June 04, 2014, 07:55:21 AM »
when yate offers iLBC mode=20 and the remote UA anwers with mode=30 then yate must use mode=30. But it doesn't....

AFAIK iLBC mode=20 must only be used if both prefer mode=20.





marian

  • Hero Member
  • *****
  • Posts: 513
    • View Profile
Re: iLBC negotiation
« Reply #1 on: June 05, 2014, 02:03:50 AM »
Can you post the SDP offer and response?
Note that in yate mode 20 and 30 are different formats.
If yate advertise mode 20 and receives mode 30 the received format will be ignored (not enabled).

looserouting

  • Newbie
  • *
  • Posts: 23
    • View Profile
Re: iLBC negotiation
« Reply #2 on: June 05, 2014, 07:24:26 AM »
i can provide examples if you really need them.

I think you're right. The probem is that yate have to switch the format.
Isn't SDPMedia:update the place where this should/could be handled ?

So for now if someone wants to use iLBC with yate he must disable ilbc20 or force mode=30 through ysipchan.cfg.



« Last Edit: March 19, 2015, 05:41:21 PM by looserouting »

marian

  • Hero Member
  • *****
  • Posts: 513
    • View Profile
Re: iLBC negotiation
« Reply #3 on: June 05, 2014, 08:13:24 AM »
ilbc20/ilbc30 offer/accept is configured in [codecs] section.
ilbc related options in [hacks] section are used when parsing received SDP.

SDPMedia::update() is the place where exiting media is updated from received SDP.
When the existing formats list is replaced with a new one, the first format is chosen
Some notes:
- If received formats list is empty (none offered or no acceptable format) the existing formats are not replaced
- If received formats list is not empty:
  - Local rtp: the format list is not updated if the intersection with offered formats leads to an empty list
  - Forward rtp: The formats list is always replaced with received formats

looserouting

  • Newbie
  • *
  • Posts: 23
    • View Profile
Re: iLBC negotiation
« Reply #4 on: July 18, 2014, 08:33:37 AM »
Existing media must be updated if yate offers mode20 end romote endpoint offers mode30 in SDP. So this function need to be modified to switch ilbc20 and ilbc30 in that case.

There is nothing you can do in [hacks] to make it work correctly.
There is only one option: Disable ilbc20 in [codecs]
The thing is i wanna use ilbc20 where possible.

Edit: i think since for g729 you need a license ilbc20 seems to be the best choice for a narrowband coedec. Other codecs are less common or not as good
« Last Edit: July 18, 2014, 08:42:50 AM by looserouting »

marian

  • Hero Member
  • *****
  • Posts: 513
    • View Profile
Re: iLBC negotiation
« Reply #5 on: July 18, 2014, 08:57:08 AM »
This is a feature request.
You should talk to Diana about it.

looserouting

  • Newbie
  • *
  • Posts: 23
    • View Profile
Re: iLBC negotiation
« Reply #6 on: July 21, 2014, 12:55:29 PM »
I think you don't understand the Problem. Otherwise you wouldn't call it a feature request. The negotiation of ilbc is broken. I try to find some time. Maybe a can write a patch.

looserouting

  • Newbie
  • *
  • Posts: 23
    • View Profile
Re: iLBC negotiation
« Reply #7 on: March 20, 2015, 03:08:23 AM »
I think this the following loop in SDPMedia::update that needs change

Code: [Select]
else if (m_formats && !force) {
    // from received list keep only already offered formats
    ObjList* l1 = tmp.split(',',false);
    ObjList* l2 = m_formats.split(',',false);
    for (ObjList* fmt = l1->skipNull(); fmt; ) {
if (l2->find(fmt->get()->toString()))
    fmt = fmt->skipNext();
else {
    fmt->remove();
    fmt = fmt->skipNull();
}
    }

ilbc20 should not be removed when there is ilbc30 in ObjList l2 and ilbc30 should not be removed when there is ilbc20 in ObjList l2.
For that the else part must be extended to something like:

Code: [Select]
if (  the format is ilbc20 and there is ilbc30 in ObjList l2) {
                    put ilbc30 in fmt instead of ilbc20;
}elseif  ( the format is ilbc30 and there is ilbc20 in ObjList l2)  {
                    fmt = fmt->skipNext();
}else {
    fmt->remove();
    fmt = fmt->skipNull();
}

I don't know yet which opportunities the Object list class and the string class give me. I am no real programmer and I will nedd some time to fully unterstand the code. and i don't even really know if this is the right approach

also something similar have to be done if only a single format is received.(few line above that code)

comments on this are appreciated

« Last Edit: March 20, 2015, 06:45:16 AM by looserouting »

looserouting

  • Newbie
  • *
  • Posts: 23
    • View Profile
Re: iLBC negotiation
« Reply #8 on: March 20, 2015, 07:40:50 AM »
many UA's are buged and yate is too. ( speaking of ilbc of course  :D )

ilbc_forced seems to be a quick and dirty hack that doesn't always work. Especially beacuse it's global but you are dealing with normal UA's - where you don't need the hack - and with buged UA's.  you only want to set it for particular users otherwise you'll brake compatibility with working UA's.

My approach is to first fix yates behavior. Than you could make a channel-variable out of ilbc_forced to deal with particular UA's.

right know it all seems messed up