7 May
2007
7 May
'07
10:07 p.m.
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@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(a)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(a)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.
**********************************************************************