[Serdev] [Patch] Ability to check negative reply code in the failure_route

Atle Samuelsen clona at camaro.no
Tue Mar 8 12:43:07 UTC 2005


Hi Maxim,
* Maxim Sobolev <sobomax at portaone.com> [050308 13:07]:
> Atle Samuelsen wrote:
> >Hi Dan and Juha,
> >
> >* Dan Pascu <dan at ag-projects.com> [050308 12:36]:
> >
> >>On Tuesday 08 March 2005 12:27, Juha Heinanen wrote:
> >>
> >>>Dan Pascu said:
> >>>
> >>>>This can help implement fallback failure
> >>>>routes
> >>>>for PSTN for example, where I need to know if the 408 was internally
> >>>>generated by SER because the PSTN gateway didn't respond in which case I
> >>>>want
> >>>>to try another PSTN gateway, or it came from the PSTN gateway because 
> >>>>the
> >>>>PSTN phone was not answered in a given time, in which case I don't want
> >>>>to try the second gateway.
> >>>
> >>>perhaps your problem is again * spesific, because in cisco gws, you get
> >>>immediately back some reply if the gw is alive.
> >>
> >>I use cisco gateways for outbound. But when I process the 408 I don't 
> >>know if the gateway has already send any intermediate answers (like 183) 
> >>and is alive, or it has not replied at all.
> >
> >
> >I agree with Dan here, this will be a issue even if this is from a cisco
> >gw, or a Sipura or what ever...
> >
> >if you use AVP's, and set the fr_inv_timer to 30 sec, you will most
> >likely get a 100/18X respons.
> >
> >After 30 sec, ser timesout, and generates internally a 408 message.
> >
> >therefor it would be nice to be able to know if the reply was generated
> >internally (even if it was done as easy as when ser generates a 408, it
> >adds a headerflag with reason, and we just pull out the reason in a
> >regexp)
> 
> I don't think that it really matters. The only thing that matters is 
> that the call has not reached final recepient (which is what 408 
> indicates regardless of its origin). However, you can easily modify tm 
> to set some AVP in the case when 408 is generated locally.

That may be, I dont know the TM core that good that I could do it as
easy as you say. 

But if I got the RFC right (3261) In the case that SER generates a local
timeout, because one of it's own timers went out, and made the invite
invalid, it should use a 504 Server Time-out respons(section 21.5.5),
else use a 408 (section 21.4.9).


- Atle

(PS. dont shoot me if Im wrong on this, It may be that I've read the RFC
wrong)




More information about the Serdev mailing list