[Serdev] [BUG] Created: (SER-73) Better branch picking algorithm

[Atle Samuelsen]

Hi Greger, 

I see your perspective, What I ment, was to make it only changeable as a
module parameter, witch either could be added as "if changed, no
ser-help will be given" or something like that. 

but, from a support perspective, it's insaine to make it configurable

- Atle


* Greger V. Teigre <greger at teigre.com> [050922 19:46]:
> Sounds good, but does the RFC really open up room for so much variation 
> (yes, I read the excerpt)?  I understand that there may be situations where 
> different handling of branch codes is good, but from an onsip.org 
> perspective there are already too many ways users can create new problems 
> for themselves (not realizing the implications of changes they do).
>    So, I would suggest only allowing different priorities through code 
> changes and not ser.cfg module parameters :-)
> g-)
> 
> 
> ----- Original Message ----- 
> From: "Atle Samuelsen" <clona at cyberhouse.no>
> To: "Martin Koenig" <martin.koenig at toplink.de>
> Cc: <serdev at lists.iptel.org>
> Sent: Wednesday, September 21, 2005 06:29 PM
> Subject: Re: [Serdev] [BUG] Created: (SER-73) Better branch picking 
> algorithm
> 
> 
> >Hi Jan and Martin,
> >
> >how about making the sorting somewhat possible to define, maybe as a
> >module parameter?
> >
> >This ways, it could be choosen by the "admins".
> >
> >
> >-Atle
> >
> >* Martin Koenig <martin.koenig at toplink.de> [050921 17:54]:
> >>Hello Jan,
> >>
> >>> -----Original Message-----
> >>> From: serdev-bounces at lists.iptel.org
> >>> [mailto:serdev-bounces at lists.iptel.org] On Behalf Of Jan Janak (JIRA)
> >>> Sent: Wednesday, September 21, 2005 1:28 PM
> >>> To: serdev at lists.iptel.org
> >>> Subject: [Serdev] [BUG] Created: (SER-73) Better branch
> >>> picking algorithm
> >>
> >>>
> >>> Branch picking algorithm (draft):
> >>>
> >>> 1) 200 OK
> >>> 2) local 487 (triggered by incoming CANCEL messages)
> >>> 3) 6xx
> >>> 4) Lowest response class
> >>>
> >>> Within 4xx class:
> >>> 1) 401 (Unauthorized)
> >>> 2) 407 (Proxy Authentication Required)
> >>> 3) 415 (Unsupported Media Type)
> >>> 4) 423 (Interval Too Brief)
> >>> 5) 484 (Address Incomplete)
> >>>
> >>> the rest in the order of their response codes.
> >>
> >>May I suggest to give priority also to responses like 486 (User Busy) and
> >>480 (Temporarliy Not Available) over i.e. 404 (Not Found).
> >>
> >>This is important for PSTN gatewaying.
> >>
> >>GW -> SER -> REGISTRAR1 -> User (responds 486)
> >>          -> REGISTRAR2 (responds 404)
> >>
> >>Ser creates two branches to two registrars. Now obviously the Gateway
> >>initiating the call should receive the 486 (resulting in User Busy Tone)
> >>rather than 404 (resulting in Unallocated Number Announcement).
> >>
> >>Or maybe it would make sense after all to forward the response codes in
> >>descending order of the response codes?
> >>
> >>What do you guys think?
> >>
> >>Best regards,
> >>Martin
> >>
> >>
> >>_______________________________________________
> >>Serdev mailing list
> >>serdev at lists.iptel.org
> >>http://lists.iptel.org/mailman/listinfo/serdev
> >>
> >
> >_______________________________________________
> >Serdev mailing list
> >serdev at lists.iptel.org
> >http://lists.iptel.org/mailman/listinfo/serdev
> >
> 
>