[Serusers] Remote Party ID

Charles Galea charles.galea at maltacom.com
Wed Jul 14 14:19:15 CEST 2004


Hi all,

we have managed to conclude that the problem must be coming for the IOS
version. We have switched from the original gateway 3620 running 12.2(15)T12
to a 2610 running IOS version 12.3(6b) and it worked immediately without any
problems. In fact if the remote party id header is present the gateway will
pass the number in this header; if remote party id is not present, and a
valid number is present in the From header,  it will map it in the calling
party number field correctly also.

Thanks once again for your help.


Regards,

Charles and Andrew




----- Original Message -----
From: "Ezequiel Colombo" <ecolombo at arcotel.net>
To: "Charles Galea" <charles.galea at maltacom.com>
Cc: <serusers at lists.iptel.org>
Sent: Wednesday, July 14, 2004 13:56
Subject: Re: [Serusers] Remote Party ID


> 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