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

[Carsten Bock]

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