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@openser.org > http://openser.org/cgi-bin/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
