R: [Serusers] sequential forking and merged request

Greger V. Teigre greger at teigre.com
Mon May 7 21:07:29 CEST 2007


Well, in this case you need to test for the status code in the failure 
route. If you fork off several INVITEs in your main route, you don't get 
into the failure route until all branches failed. So, I still don't 
understand how you do it.
Anyway, you want to avoid it, because you have a gateway that does not 
follow the RFC...
g-)

Zappasodi Daniele wrote:
>
> I have written a module that choose the next client reading the 
> destination from a db, but I can easily obtain the same scenario with 
> the basic serial forking example:
>
>  route{
>         [...]
>        t_on_failure("1");
>        t_relay();
>  }
>
>  failure_route[1] {
>        append_branch("sip:number1 at mygw.com");
>        log(1,"first redirection\n");
>        t_on_failure("2");
>        t_relay();
>  }
>
>  failure_route[2] {
>        append_branch("sip:number2 at mygw.com");
>        log(1, "second redirection to the same gateway, but different 
> number\n");
>        t_relay();
>  }
>
>
>
> -----Messaggio originale-----
> Da: Greger V. Teigre [mailto:greger at teigre.com]
> Inviato: lun 07/05/2007 15.48
> A: Zappasodi Daniele
> Cc: serusers at lists.iptel.org
> Oggetto: Re: [Serusers] sequential forking and merged request
>
> Any device implementing UA functionality should follow RFC3261. But I'm
> not sure how you manage to fork off two INVITEs to the same gateway? I
> would start there.
> g-)
>
> Zappasodi Daniele wrote:
> > Hello,
> > I have a question about sequential forking and Merged Request.
> > If in a forking SER calls two lines of the same client (different 
> numbers and different Request-URIs) it refuses the second call with 
> 482 (Cisco and Snom multiline phone for example) according with RFC 
> 3261 section 8.2.2.2 because the two INVITEs have the same Call-Id, 
> From tag and Cseq.
> > If this behaviour is reasonable with a phone, it could not be 
> acceptable for other types of client, first of all SIP-PSTN gateway.
> > Is it correct this RFC interpretation? Maybe is this section 
> inappropriate for gateways? 
> > Is there something that I can do in the config file?
> >
> >
> > **********************************************************************
> > The information in this message is confidential and may be legally
> > privileged. It is intended solely for the addressee. Access to this 
> message
> > by anyone else is unauthorized. If you are not the intended 
> recipient, any
> > disclosure, copying, or distribution of the message, or any action or
> > omission taken by you in reliance on it, is prohibited and may be 
> unlawful.
> > Please immediately contact the sender if you have received this 
> message inerror.
> >
> > **********************************************************************
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Serusers mailing list
> > Serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> >  
>
> **********************************************************************
> The information in this message is confidential and may be legally
> privileged. It is intended solely for the addressee. Access to this message
> by anyone else is unauthorized. If you are not the intended recipient, any
> disclosure, copying, or distribution of the message, or any action or
> omission taken by you in reliance on it, is prohibited and may be unlawful.
> Please immediately contact the sender if you have received this message inerror.
>
> **********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070507/afc8bc2b/attachment.htm>


More information about the sr-users mailing list