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@mygw.com");
log(1,"first redirection\n");
t_on_failure("2");
t_relay();
}
failure_route[2] {
append_branch("sip:number2@mygw.com");
log(1, "second redirection to the same gateway, but different number\n");
t_relay();
}
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: lun 07/05/2007 15.48
A: Zappasodi Daniele
Cc: serusers@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@lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>