[OpenSER-Devel] SF.net SVN: openser: [2835] trunk/modules/sl

Bogdan-Andrei Iancu bogdan at voice-system.ro
Fri Oct 5 15:41:00 CEST 2007


Hi Carsten,

If I'm not wrong, it is exactly the case presented by Klaus.
I do not say this functionality make no sense, but currently there is 
not way to get it via a fast patch.

regards,
Bogdan

Carsten Bock wrote:
> Hi all,
>
> i would like to add another use-case, where using sl_send_reply in a
> reply route makes sense to me:
> After a update, one of our main carriers is sending 183 replies without
> SDP-Body. It would be cool, if i could change this into a 180 Ringing
> reply...
> (Of course, we could claim to the carrier, that this is a bug in their
> gateway, but until it's fixed, it'll take several months ;-)
>
> Just my 0.02$,
> Carsten
>
>
> Am Donnerstag, den 04.10.2007, 14:21 +0300 schrieb Bogdan-Andrei Iancu:
>   
>> Hi Henning,
>>
>> I have some concerns (even on a first view things work) about couple of 
>> issues:
>>
>>     - there are some direct access to the sip_msg structure as a 
>> requests (the struct contains a union for reply and requests) and the 
>> read information will be bogus. Like we have a filter:
>>           msg->first_line.u.request.method_value==METHOD_ACK
>>       which will be bogus for a reply.
>>
>>     - routing - the module determins where to send the reply in two ways:
>>             1) based on top most via (assuming a request is processed), 
>> so for a reply it will be again bogus
>>             2) based on the received field from sip_msg struct - to send 
>> it where the request came from; again bogus....
>>
>> It will be safer to undo the change until we understand all the 
>> implications...
>>
>> Thanks and regards,
>> Bogdan      
>>
>> Henning Westerholt wrote:
>>     
>>> On Wednesday 03 October 2007, Bogdan-Andrei Iancu wrote:
>>>   
>>>       
>>>> Hi Henning,
>>>>
>>>> I'm not sure this is correct. The sl_send_reply() function expects to
>>>> receive a sip requests from the script, but in onreply_route you have a
>>>> sip reply.....it might by bogus....
>>>>
>>>> and why do you want to send a reply while processing a received reply?
>>>>     
>>>>         
>>> Hello Bogdan,
>>>
>>> thanks for your comment. We did some tests, it seems to work. But if you're 
>>> unsure about this change, i will revert it and it gets some more testing.
>>>
>>> Let me explain one usecase for this:
>>>
>>> In a parallel forking scenario you get several 183s with SDP. You don't want 
>>> that your customers hear more than one ringtone or answer machine in parallel 
>>> on the phone. So its necessary to drop the 183 and send a 180 instead.
>>>
>>> Perhaps there exists another possiblity to achieve this?
>>>
>>> Cheers,
>>>
>>> Henning
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> Devel mailing list
>> Devel at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>     
>
>
>   




More information about the Devel mailing list