Nested join optimisations not currently documented

[benlangfeld]

[01/11/2012 19:54:15] Jose de Castro: @benK is there any reason we are not doing a nested join for the second leg?
[01/11/2012 19:54:43] Ben Langfeld: Because Adhearsion wants more flexibility by default
[01/11/2012 19:57:02] Jose de Castro: hmm. ok. we have a bunch of optimizations for "transfer" cases in moho that are not being used
[01/11/2012 19:57:07] Jose de Castro: should work either way of course
[01/11/2012 19:57:26] Jose de Castro: just wondering why really since semantically it seems to fit quite well
[01/11/2012 19:57:54] Ben Langfeld: just because Adhearsion normally does a bunch of stuff in between answer and join
[01/11/2012 19:58:05] Ben Langfeld: We can optimise, but it shouldn't be necessary
[01/11/2012 19:59:47] Jose de Castro: well, it does have an impact on user experience as well
[01/11/2012 20:00:04] Jose de Castro: for example, the caller won't hear the actual ring tone of the person they are calling
[01/11/2012 20:00:48] Jose de Castro: are you answering the call before dialing the second leg?
[01/11/2012 20:00:51] Jose de Castro: or just accepting?
[01/11/2012 20:01:01] Jose de Castro: answer will stop the ringing
[01/11/2012 20:01:16] Jose de Castro: which means the caller is just hearing silence until the other party picks up
[01/11/2012 20:01:40] Ben Langfeld: accepting
[01/11/2012 20:01:56] Jose de Castro: ok. they should still hear they carriers;s standard ring then
[01/11/2012 20:02:08] Jose de Castro: but not the B parties custom ring tone if they have one
[01/11/2012 20:02:21] Jose de Castro: not a huge deal but something to consider for adhearsion
[01/11/2012 20:02:58] Jose de Castro: there a lots of little things like that for a good b2bua
[01/11/2012 20:03:48] Ben Langfeld: Can you enumerate the differences between those scenarios (accept/answer & join, vs nested join) somewhere?
[01/11/2012 20:04:32] Ben Langfeld: Or are they in some existing docs?
[01/11/2012 20:04:40] Ben Langfeld: They should really be in the Rayo spec
[01/11/2012 20:05:40] Jose de Castro: early media is the main one
[01/11/2012 20:07:18] Jose de Castro: but also we have the different join params: force,  BRIDGE_EXCLUSIVE, etc... where you can leverage the rayo server to handle a lot of the timing issues that could arise from attempting to join a call to multiple parties
[01/11/2012 20:07:53] Ben Langfeld: Ok, we don't have those in the spec
[01/11/2012 20:08:11] Ben Langfeld: I'll file an issue. Assign to you or Martin?

[benlangfeld]

@loopingrage Can you please enumerate these issues?

[benlangfeld]

We're getting repeated questions about this topic, and this is becoming more and more urgent. @loopingrage Do you think you will be able to provide this info soon?

[benlangfeld]

@loopingrage It would be great if we could get these soon so that we can ensure we implement ringback passthrough in B2BUA scenarios correctly.

[benlangfeld]

@mpermar Could you shed any light on this for me?

[mpermar]

Not really. So far nested join currently just embeds a join within a dial. So the standard join attributes can be passed through, i.e. direction, media and type. Not sure if that was what you were referring to.

[benlangfeld]

This is more about when the join takes place and ringback concerns. Any chance you could prod Jose on some further details?

Em 21/01/2014, às 16:09, mpermar notifications@github.com escreveu:

Not really. So far nested join currently just embeds a join within a dial. So the standard join attributes can be passed through, i.e. direction, media and type. Not sure if that was what you were referring to.

— Reply to this email directly or view it on GitHub.

[mpermar]

Right. Try to ping him on skype. He's probably getting thousands of emails these days.

[benlangfeld]

Yeah, I tried, I havn't been able to get a response. Not sure what to turn to next.

[skalogirou]

@loopingrage did you have any progress on this issue. Is there any way we could contribute to get a solution on this faster. Thank you