[Serusers] Remote Party ID
Ezequiel Colombo
ecolombo at arcotel.net
Wed Jul 14 13:56:03 CEST 2004
In my opinion your problem cannot relate to redirect-number.
Can you provide the "debug ccsip message", "debug ccsip events" and "debug
isdn q931"
of a test call that dont put the Remote-Party-ID into calling-number
information ?
thanks
----- Original Message -----
From: "Charles Galea" <charles.galea at maltacom.com>
To: "Marcello Lupo" <lupo at itspecialist.it>; <serusers at lists.iptel.org>
Sent: Wednesday, July 14, 2004 3:02 AM
Subject: Re: [Serusers] Remote Party ID
> Hi,
>
> I cannot understand why this redirecting number is related to my problem.
> Actually my problem is that when SER forwards a call to the cisco 3620
> gateway, the gateway will not include the calling party number information
> element in the setup message, even if the INVITE will have a
Remote-Party-ID
> header.
>
> According to Q931, the redirect number in the setup message is from
network
> to user and not from user to network.
>
>
> Any ideas?
>
> Thanks
>
> Charles
>
>
> ----- Original Message -----
> From: "Marcello Lupo" <lupo at itspecialist.it>
> To: <serusers at lists.iptel.org>
> Sent: Tuesday, July 13, 2004 16:14
> Subject: Re: [Serusers] Remote Party ID
>
>
> > Hi,
> > we got the same problem on cisco 3725 and can confirm that is a problem
on
> the
> > Redirecting Number. We tried to move the cisco from user to network
(with
> > protocol net5) as stated from cisco documentation but the Cisco still
> don't
> > put the Redirecting Number in to the ISDN Setup.
> >
> > On our platform the Remote-Party-ID is working properly.
> >
> > Bye,
> > MArcello
> >
> >
> > On Tuesday 13 July 2004 14:38, Ezequiel Colombo wrote:
> > > The Remote-Party-Id must map to calling-party-number in a Cisco
gateway
> and
> > > this bug like to be a problem in redirect number.
> > > I dont see that this bug is related to SIP rpid.
> > > Also, the bug is reported in AS5300 platform
> > >
> > > ------ bug description -------
> > > Symptoms: Some Cisco ISDN switches do not support Redirecting Number
> (RDN)
> > > Information Element (IE) from user to network.
> > >
> > > Conditions: This symptom is observed on Cisco NTT, DMS100, and NET5
> > > switches.
> > > ------ bug description -------
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Steve Blair" <blairs at isc.upenn.edu>
> > > To: "Charles Galea" <charles.galea at maltacom.com>
> > > Cc: <serusers at lists.iptel.org>
> > > Sent: Tuesday, July 13, 2004 9:30 AM
> > > Subject: Re: [Serusers] Remote Party ID
> > >
> > > > There is a Cisco bug report that may also affect you. It is
> > > > CSCeb20959, Some Cisco ISDN switches do not support
> > > > Redirecting Number (RDN) Information Element (IE) from
> > > > user to network.
> > > >
> > > > _Steve
> > > >
> > > > Charles Galea wrote:
> > > > >Thanks a lot,
> > > > >
> > > > >i have included an authentication check before append_rpid_hf() and
> now
> > >
> > > it
> > >
> > > > >is working fine. Now I am trying to figure out why my 3600 gateway
is
> > >
> > > still
> > >
> > > > >not sending the calling party field in the setup message.
> > > > >
> > > > >Regards,
> > > > >
> > > > >Charles
> > > > >
> > > > >
> > > > >----- Original Message -----
> > > > >From: "Bogdan-Andrei IANCU" <iancu at fokus.fraunhofer.de>
> > > > >To: "Charles Galea" <charles.galea at maltacom.com>
> > > > >Cc: <serusers at lists.iptel.org>; "'Andrew Caruana'"
> > >
> > > <andrew.caruana at maltacom.com>
> > >
> > > > >Sent: Monday, July 12, 2004 13:58
> > > > >Subject: Re: [Serusers] Remote Party ID
> > > > >
> > > > >>rpid is fetched from db during an authentication check. so, if you
> > > > >> don't have any authentication before append_rpid_hf(), we will
not
> > > > >> have any
> > > > >
> > > > >rpid.
> > > > >
> > > > >>bogdan
> > > > >>
> > > > >>Charles Galea wrote:
> > > > >>>We have downloaded the latest ser software from cvs in order to
> > > > >>>support appending of remote party id while using mysql as the ser
> > > > >>>database.
> > > > >>>After compiling and installing the ser software we included the
> auth
> > > > >>>and auth_db parameters and also the append_rpid_hf() function in
> our
> > > > >>>ser.cfg file as shown below.
> > > > >>>
> > > > >>>SER server starts and registration is successfull however when
> > > > >>>forwarding to the pstn gateway, ser will not append the remote
> party
> > > > >>>id header, even if the rpid and uri columns in mysql database are
> > > > >>>populated accordingly using the serctl add rpid command. Calls
are
> > > > >>>also successfull however the gateway will not include the calling
> > > > >>>party number in the setup message because the rpid header is
> missing.
> > > > >>>
> > > > >>>
> > > > >>>Any ideas please?
> > > > >>>
> > > > >>>Thanks
> > > > >>>
> > > > >>>Charles and Andrew
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>># ----------- global configuration
> parameters ------------------------
> > > > >>>
> > > > >>>#debug=3 # debug level (cmd line: -dddddddddd)
> > > > >>>#fork=yes
> > > > >>>#log_stderror=no # (cmd line: -E)
> > > > >>>
> > > > >>>/* Uncomment these lines to enter debugging mode
> > > > >>>debug=7
> > > > >>>fork=no
> > > > >>>log_stderror=yes
> > > > >>>*/
> > > > >>>
> > > > >>>check_via=no # (cmd. line: -v)
> > > > >>>dns=no # (cmd. line: -r)
> > > > >>>rev_dns=no # (cmd. line: -R)
> > > > >>>#port=5060
> > > > >>>#children=4
> > > > >>>fifo="/tmp/ser_fifo"
> > > > >>>
> > > > >>># ------------------ module
> loading ----------------------------------
> > > > >>>
> > > > >>>loadmodule "/our_downloads/sip_router/modules/mysql/mysql.so"
> > > > >>>#loadmodule "//lib/ser/modules/mysql.so"
> > > > >>>
> > > > >>>loadmodule "//lib/ser/modules/sl.so"
> > > > >>>loadmodule "//lib/ser/modules/tm.so"
> > > > >>>loadmodule "//lib/ser/modules/rr.so"
> > > > >>>loadmodule "//lib/ser/modules/maxfwd.so"
> > > > >>>loadmodule "//lib/ser/modules/usrloc.so"
> > > > >>>loadmodule "//lib/ser/modules/registrar.so"
> > > > >>>loadmodule "//lib/ser/modules/textops.so"
> > > > >>>
> > > > >>># Uncomment this if you want digest authentication
> > > > >>># mysql.so must be loaded !
> > > > >>>loadmodule "//lib/ser/modules/auth.so"
> > > > >>>loadmodule "//lib/ser/modules/auth_db.so"
> > > > >>>
> > > > >>>
> > > > >>>#loadmodule "//lib/ser/modules/acc.so"
> > > > >>>
> > > > >>># ----------------- setting module-specific
> parameters ---------------
> > > > >>>
> > > > >>># -- usrloc params --
> > > > >>>
> > > > >>>#modparam("usrloc", "db_mode", 0)
> > > > >>>
> > > > >>># Uncomment this if you want to use SQL database
> > > > >>># for persistent storage and comment the previous line
> > > > >>>modparam("usrloc", "db_mode", 1)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>># -- auth params --
> > > > >>>
> > > > >>>
> > > > >>>modparam("auth_db", "use_rpid", 1)
> > > > >>>modparam("auth_db", "rpid_column", "rpid")
> > > > >>>modparam("auth", "rpid_prefix", "<sip:")
> > > > >>>modparam("auth", "rpid_suffix",
> > > > >>>"@testphone.com>:party=calling;screen=no;privacy=off")
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>># Uncomment if you are using auth module
> > > > >>>#
> > > > >>>modparam("auth_db", "calculate_ha1", yes)
> > > > >>>#
> > > > >>># If you set "calculate_ha1" parameter to yes (which true in this
> > > > >>>config),
> > > > >>># uncomment also the following parameter)
> > > > >>>#
> > > > >>>modparam("auth_db", "password_column", "password")
> > > > >>>
> > > > >>># -- rr params --
> > > > >>># add value to ;lr param to make some broken UAs happy
> > > > >>>modparam("rr", "enable_full_lr", 1)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>># ------------------------- request routing
> logic -------------------
> > > > >>>
> > > > >>># main routing logic
> > > > >>>
> > > > >>>route{
> > > > >>>
> > > > >>> # initial sanity checks -- messages with
> > > > >>> # max_forwards==0, or excessively long requests
> > > > >>> if (!mf_process_maxfwd_header("10")) {
> > > > >>> sl_send_reply("483","Too Many Hops");
> > > > >>> break;
> > > > >>> };
> > > > >>> if ( msg:len > max_len ) {
> > > > >>> sl_send_reply("513", "Message too big");
> > > > >>> break;
> > > > >>> };
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> # we record-route all messages -- to make sure that
> > > > >>> # subsequent messages will go through our proxy; that's
> > > > >>> # particularly good if upstream and downstream entities
> > > > >>> # use different transport protocol
> > > > >>> record_route();
> > > > >>> # loose-route processing
> > > > >>> if (loose_route()) {
> > > > >>> t_relay();
> > > > >>> break;
> > > > >>> };
> > > > >>>
> > > > >>>
> > > > >>> # if the request is for other domain use UsrLoc
> > > > >>> # (in case, it does not work, use the following command
> > > > >>> # with proper names and addresses in it)
> > > > >>> if (uri=~"testphone.com") {
> > > > >>> lookup("aliases");
> > > > >>> if (method=="REGISTER") {
> > > > >>>
> > > > >>>#Uncomment this if you want to use digest authentication
> > > > >>> if (!www_authorize("testphone.com", "subscriber")) {
> > > > >>> www_challenge("testphone.com", "0");
> > > > >>> append_rpid_hf();
> > > > >>> break;
> > > > >>> };
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> save("location");
> > > > >>> break;
> > > > >>> };
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> if (uri=~"^sip:21") {
> > > > >>> append_rpid_hf();
> > > > >>> forward(a valid ip address for the gateway
> was
> > > > >>>inserted here);
> > > > >>> break;
> > > > >>> }
> > > > >>>
> > > > >>> if (uri=~"^sip:123") {
> > > > >>> forward(a valid ip address for the gareway
> was
> > > > >>>inserted here);
> > > > >>> break;
> > > > >>> }
> > > > >>>
> > > > >>>
> > > > >>> # native SIP destinations are handled using our USRLOC DB
> > > > >>> if (!lookup("location")) {
> > > > >>> sl_send_reply("404", "Not Found");
> > > > >>> break;
> > > > >>> };
> > > > >>> };
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> # forward to current uri now; use stateful forwarding; that
> > > > >>> # works reliably even if we forward from TCP to UDP
> > > > >>> if (!t_relay()) {
> > > > >>> sl_reply_error();
> > > > >>> };
> > > > >>>
> > > > >>>
> > > > >>>}
> > > >>>
> > >
>
>>>------------------------------------------------------------------------
> > > >>>
> > > > >>>_______________________________________________
> > > > >>>Serusers mailing list
> > > > >>>serusers at lists.iptel.org
> > > > >>>http://lists.iptel.org/mailman/listinfo/serusers
> > > > >
> > > > >_______________________________________________
> > > > >Serusers mailing list
> > > > >serusers at lists.iptel.org
> > > > >http://lists.iptel.org/mailman/listinfo/serusers
> > > >
> > > > --
> > > >
> > > > ISC Network Engineering
> > > > The University of Pennsylvania
> > > > 3401 Walnut Street, Suite 221A
> > > > Philadelphia, PA 19104
> > > >
> > > >
> > > > voice: 215-573-8396
> > > >
> > > > 215-746-7903
> > > >
> > > > fax: 215-898-9348
> > > >
> > > > sip:blairs at upenn.edu
> > > >
> > > > _______________________________________________
> > > > Serusers mailing list
> > > > serusers at lists.iptel.org
> > > > http://lists.iptel.org/mailman/listinfo/serusers
> > >
> > > _______________________________________________
> > > Serusers mailing list
> > > serusers at lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
More information about the sr-users
mailing list