<div dir="ltr">Even better, How about being able to send an marked OPTIONS to all in-dialog UACs and expect an answer, whatever it is to know that the UAC is actually reachable, hence still on the call?<br><br><div class="gmail_quote">
On Tue, Aug 26, 2008 at 2:36 PM, Ovidiu Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com">osas@voipembedded.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, Aug 26, 2008 at 6:23 AM, Bogdan-Andrei Iancu<br>
<div class="Ih2E3d"><<a href="mailto:bogdan@voice-system.ro">bogdan@voice-system.ro</a>> wrote:<br>
</div><div><div></div><div class="Wj3C7c">> Hi Dan,<br>
><br>
> Dan Pascu wrote:<br>
>> On Monday 25 August 2008, Bogdan-Andrei Iancu wrote:<br>
>><br>
>>> Hi,<br>
>>><br>
>>> Following the discussions (lists and private), here is the list with<br>
>>> what is to be done for OpenSIPS 1.5.<br>
>>><br>
>>> The items are grouped in two categories - what should be done for 1.5<br>
>>> (mandatory) and what would be nice to have (optional). The list does<br>
>>> not cover the contributions (patches), like the MSRP and Xcap-diff<br>
>>> modules uploaded by ag-project (which are already done).<br>
>>><br>
>>> For the grouping, an important factor was taken into consideration (as<br>
>>> you may notice, some important items were set as optional) - there are<br>
>>> plans for a complete rework on the opensips architecture that will put<br>
>>> things into a new light - a discussion about OpenSIPS 2.0 will be<br>
>>> started sooner on a separate thread.<br>
>>><br>
>>><br>
>>> Mandatory:<br>
>>><br>
>>> 1) TM - cancel processing (Reason header, cancel per branch from<br>
>>> script, auto processing in script)<br>
>>><br>
>>> 2) TM - transaction building - split in 2 phases to be able to go<br>
>>> stateful asap (for retransmissions), but to be able to apply changes<br>
>>> (like lumps, flags, etc) until you do relay.<br>
>>><br>
>>> 3) dialog - more work on BYE (sending byes from script makes sense ?)<br>
>>><br>
>><br>
>> Maybe a way to make the dialog module send the BYEs when the dialog<br>
>> expires.<br>
>><br>
> [bogdan]<br>
> Yes, that is one idea also - to mark the dialog if BYE should be<br>
> generated on dialog timeout.<br>
</div></div>[ovidiu]<br>
how about going with a more general approachand use a new route: timeout_route.<br>
the admin can decide what to do with respect to that dialog:<br>
- send a BYE<br>
- re-arm the timer<br>
<div><div></div><div class="Wj3C7c"><br>
>><br>
>>> 7) PV - try to find a consistent NULL behaviour for all script<br>
>>> variables<br>
>>><br>
>><br>
>> If this would require too much effort, like rewriting large portions of<br>
>> the pvar system, then I think it's not worth it, in the light of this<br>
>> being unnecessary with the new design of 2.0. I would rather put the<br>
>> effort and work in 2.0, since there are workarounds this and it can be<br>
>> lived with.<br>
>><br>
> [bogdan]<br>
><br>
> that is true - first we will see what is the required effort - if too<br>
> high, it will be skipped.<br>
>><br>
>>> 8) start the work on introducing "context" for message processing - any<br>
>>> future work on async processing depends on this.<br>
>>><br>
>><br>
>> same as above. contexts will be unnecessary with the new design of 2.0.<br>
>><br>
> [bogdan]<br>
> Well, even in 2.0, some message context will be needed, but on a smaller<br>
> scale - but let's have this discussion when taking about 2.0 :)<br>
>><br>
>>> 9) starting working on a B2BUA module based on TM (like for topology<br>
>>> hiding)<br>
>>><br>
>><br>
>> same here. 2.0 would allow this to be built easily, so I'd rather not<br>
>> invest the effort for 1.5.<br>
>><br>
> [bogdan]<br>
><br>
> design discussions should be started - depending of how it will fit in<br>
> 2.0 design, we will see about the implementation.<br>
>><br>
>>> Good to have:<br>
>>><br>
>>><br>
>>> 1) dialog integration in NAT and SIPTRACE modules - do control at<br>
>>> dialog level instead of transaction level<br>
>>><br>
>><br>
>> nat_traversal and mediaproxy already have dialog integration. dialog<br>
>> integration in siptrace would be nice though.<br>
>><br>
>><br>
>>> 3) db_mysql - prepared statements to speedup a bit<br>
>>><br>
>><br>
>> again, if the effort is too big, not sure if this item is worth pursuing,<br>
>> as 2.0 will not need it (most likely).<br>
>><br>
>><br>
>>> 8) AVPs - use auto aliasing everywhere - aliases in script and IDs<br>
>>> internally - this will make the AVP easier to use and less confusing<br>
>>> (having only $avp(name)) and also more efficient (internally all AVPs<br>
>>> will be $avp(i:id))<br>
>>><br>
>><br>
>> same here. too much effort for something that will go away and brings no<br>
>> real enhancements other that some speedups and a simpler way to work with<br>
>> avp aliases.<br>
>><br>
> [bogdan]<br>
> Correct - this is the reason for having this items on good-to-have.<br>
><br>
><br>
> Regards,<br>
> Bogdan<br>
><br>
><br>
> _______________________________________________<br>
</div></div>> Devel mailing list<br>
> <a href="mailto:Devel@lists.opensips.org">Devel@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/devel" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/devel</a><br>
<div><div></div><div class="Wj3C7c">><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>